Includes `alloc_zeroed` method that `RawVec` has come to depend on.
Exposed private `Layout::from_size_align` ctor to be `pub`, and added
explicit conditions for when it will panic (namely, when `align` is
not power-of-two, or if rounding up `size` to a multiple of `align`
overflows). Normalized all `Layout` construction to go through
`Layout::from_size_align`.
Addressed review feedback regarding `struct Layout` and zero-sized
layouts.
Restrict specification for `dealloc`, adding additional constraint
that the given alignment has to match that used to allocate the block.
(This is a maximally conservative constraint on the alignment. An open
question to resolve (before stabilization) is whether we can return to
a looser constraint such as the one previously specified.)
Split `fn realloc_in_place` into separate `fn grow_in_place` and `fn
shrink_in_place` methods, which have default impls that check against
usable_size for reuse. Make `realloc` default impl try `grow_in_place`
or `shrink_in_place` as appropriate before fallback on
alloc+copy+dealloc.
Drive-by: When reviewing calls to `padding_needed_for`, discovered
what I think was an over-conservative choice for its argument
alignment. Namely, in `fn extend`, we automatically realign the whole
resulting layout to satisfy both old (self) and new alignments. When
the old alignment exceeds the new, this means we would insert
unnecessary padding. So I changed the code to pass in `next.align`
instead of `new_align` to `padding_needed_for`.
Replaced ref to `realloc_in_place` with `grow_in_place`/`shrink_in_place`.
Revised docs replacing my idiosyncratic style of `fn foo` with just
`foo` when referring to the function or method `foo`.
(Alpha-renamed `Allocator` to `Alloc`.)
Post-rebased, added `Debug` derive for `allocator::Excess` to satisfy
`missing_debug_implementations`.
bors [Thu, 15 Jun 2017 06:52:42 +0000 (06:52 +0000)]
Auto merge of #42625 - michaelwoerister:dep-node-debug, r=nikomatsakis
incr.comp.: Make DepNode's std::fmt::Debug implementation useful again.
With #42537 a regular `DepNode` only contains an opaque hash as its identifier. In most cases, this hash is actually a `DefPathHash` and we can reconstruct the `DefId` it came from via a table lookup --- and then use that to print something intelligible for debug outputs. For cases where we cannot reconstruct information from the DepNode's hash, this PR will cache a string representation of the `DepNode` in a side-table. This string is later used for debug outputs.
bors [Wed, 14 Jun 2017 11:17:31 +0000 (11:17 +0000)]
Auto merge of #42523 - clarcharr:refactor_ops, r=brson
Refactor ops.rs
This refactors ops.rs into several different modules internally, as the file has gotten quite big. None of these modules are actually exported, but this should make maintaining it much easier. I've avoided the ambition of exporting the modules because they can more easily be rearranged after this commit goes through, even though it'd be cool to potentially export the modules in the future.
I've separated the creation of each file into a separate commit so that this is easier to read.
Redone version of #42269 with the movement of `RangeArgument` moved.
bors [Wed, 14 Jun 2017 08:46:14 +0000 (08:46 +0000)]
Auto merge of #42433 - marco-c:profiling, r=alexcrichton
Build instruction profiler runtime as part of compiler-rt
r? @alexcrichton
This is #38608 with some fixes.
Still missing:
- [x] testing with profiler enabled on some builders (on which ones? Should I add the option to some of the already existing configurations, or create a new configuration?);
- [x] enabling distribution (on which builders?);
- [x] documentation.
Corey Farwell [Tue, 13 Jun 2017 21:15:04 +0000 (17:15 -0400)]
Rollup merge of #42638 - arthurpaimarnold:lexer_rule_for_octal, r=petrochenkov
Possible mistake in lexer rule for octal integer
Original rule allowed for digits 0-8, but octal is 0-7.
The compiler correctly prevents you from placing an 8 in an octal, so I'm assuming this is caught on a later stage. Still, shouldn't the lexer already catch this?
Corey Farwell [Tue, 13 Jun 2017 21:15:02 +0000 (17:15 -0400)]
Rollup merge of #42597 - mark-buer:park_timeout_example_fix, r=alexcrichton
Capture elapsed duration in Thread::park_timeout example
`beginning_park.elapsed()` might return a larger value within the loop as compared to that checked in the loop conditional.
Since `Duration` arithmetic is checked, hitting such an edge case will cause a panic.
Corey Farwell [Tue, 13 Jun 2017 21:15:00 +0000 (17:15 -0400)]
Rollup merge of #42496 - Razaekel:feature/integer_max-min, r=BurntSushi
Add max and min to Ord
Pursuant to issue #25663, this PR adds max and min methods with default implementations to std::cmp::Ord. It also modifies std::cmp::max|min to internally alias to Ord::max|min, so that any overrides of the default implementations are automatically used by std::cmp::max|min.
1. The first makes `str::index` just call `SliceIndex<str>::index`. It's intended to have no behavior change, except where the two methods were inconsistent.
2. The second actually adds the overflow checking to `get(_mut)` (and tests for it)
bors [Mon, 12 Jun 2017 11:39:35 +0000 (11:39 +0000)]
Auto merge of #42537 - michaelwoerister:tcx-for-dep-node, r=nikomatsakis
incr.comp.: Make DepNode `Copy` and valid across compilation sessions
This PR moves `DepNode` to a representation that does not need retracing and thus simplifies comparing dep-graphs from different compilation sessions. The code also gets a lot simpler in many places, since we don't need the generic parameter on `DepNode` anymore. See https://github.com/rust-lang/rust/issues/42294 for details.
~~NOTE: Only the last commit of this is new, the rest is already reviewed in https://github.com/rust-lang/rust/pull/42504.~~
This PR is almost done but there are some things I still want to do:
- [x] Add some module-level documentation to `dep_node.rs`, explaining especially what the `define_dep_nodes!()` macro is about.
- [x] Do another pass over the dep-graph loading logic. I suspect that we can get rid of building the `edges` map and also use arrays instead of hash maps in some places.
bors [Mon, 12 Jun 2017 04:08:14 +0000 (04:08 +0000)]
Auto merge of #42419 - ucarion:ucarion-explain-rc-arc-abbrev, r=frewsxcv
Explicate what "Rc" and "Arc" stand for.
A person on the weekly "Easy Questions" Reddit thread [was mystified by what `Arc`/`Rc` means](https://www.reddit.com/r/rust/comments/6dyud9/hey_rustaceans_got_an_easy_question_ask_here/did87ds/). Though this is explained in various places, it's not mentioned in the documentation directly.
This PR adds an explanation of the `Rc`/`Arc` acronyms to their respective documentations. There are two things I'm not sure of:
* Does "Rc" mean "Reference Count**er**" or "Reference Count**ed**"? ~~I went with the former.~~ *Edit:* I've changed this to use the latter alternative.
* Should this information be spelled out elsewhere, such as in the docs for the `rc` module?
bors [Sun, 11 Jun 2017 18:56:27 +0000 (18:56 +0000)]
Auto merge of #42155 - seanmonstar:unimplemented, r=sfackler
core: allow messages in unimplemented!() macro
This makes `unimplemented!()` match `unreachable!()`, allowing a message and possible formatting to be provided to better explain what and/or why something is not implemented.
I've used this myself in hyper for a while, include the type and method name, to better help while prototyping new modules, like `unimplemented!("Conn::poll_complete")`, or `unimplemented!("Conn::poll; state={:?}", state)`.
bors [Sun, 11 Jun 2017 16:40:52 +0000 (16:40 +0000)]
Auto merge of #40454 - djzin:fast-swap, r=sfackler
speed up mem::swap
I would have thought that the mem::swap code didn't need an intermediate variable precisely because the pointers are guaranteed never to alias. And.. it doesn't! It seems that llvm will also auto-vectorize this case for large structs, but alas it doesn't seem to have all the aliasing info it needs and so will add redundant checks (and even not bother with autovectorizing for small types). Looks like a lot of performance could still be gained here, so this might be a good test case for future optimizer improvements.
Here are the current benchmarks for the simd version of mem::swap; the timings are in cycles (code below) measured with 10 iterations. The timings for sizes > 32 which are not a multiple of 8 tend to be ever so slightly faster in the old code, but not always. For large struct sizes (> 1024) the new code shows a marked improvement.
\* = latest commit
† = subtracted from other measurements
bors [Sat, 10 Jun 2017 19:21:24 +0000 (19:21 +0000)]
Auto merge of #42563 - eddyb:infer, r=nikomatsakis
Disentangle InferCtxt, MemCategorizationContext and ExprUseVisitor.
At some point in the past, `InferCtxt` started being used to replace an old "`Typer`" abstraction, which provided access to `TypeckTables` and had optionally type inference to account for.
That didn't play so nicely with the `'gcx`/`'tcx` split and I had to introduce `borrowck_fake_infer_ctxt`.
The situation wasn't great but it wasn't too painful inside `rustc` itself.
Recently I've found that method being used in clippy, which does need EUV (before we make it plausible to run lints on HAIR or MIR), and set out to separate inference from tables, for the sake of lint authors.
Also fixes #42435 to make it trivial to compute type layout or use EUV from lints.
The remaining uses of `TypeckTables` in `InferCtxt` are for closure kinds and signatures, used in trait selection and projection normalization. The solution there is likely to add them as bounds to `ParamEnv`.
bors [Sat, 10 Jun 2017 09:11:36 +0000 (09:11 +0000)]
Auto merge of #42556 - scottmcm:ctz-nz, r=BurntSushi
Get LLVM to stop generating dead assembly in next_power_of_two
It turns out that LLVM can turn `@llvm.ctlz.i64(_, true)` into `@llvm.ctlz.i64(_, false)` ([`ctlz`](http://llvm.org/docs/LangRef.html#llvm-ctlz-intrinsic)) where valuable, but never does the opposite. That leads to some silly assembly getting generated in certain cases.
A contrived-but-clear example https://is.gd/VAIKuC:
```rust
fn foo(x:u64) -> u32 {
if x == 0 { return !0; }
x.leading_zeros()
}
```
Generates
```asm
testq %rdi, %rdi
je .LBB0_1
je .LBB0_3 ; <-- wha?
bsrq %rdi, %rax
xorq $63, %rax
retq
.LBB0_1:
movl $-1, %eax
retq
.LBB0_3:
movl $64, %eax ; <-- dead
retq
```
I noticed this in `next_power_of_two`, which without this PR generates the following:
```asm
cmpq $2, %rcx
jae .LBB1_2
movl $1, %eax
retq
.LBB1_2:
decq %rcx
je .LBB1_3
bsrq %rcx, %rcx
xorq $63, %rcx
jmp .LBB1_5
.LBB1_3:
movl $64, %ecx ; <-- dead
.LBB1_5:
movq $-1, %rax
shrq %cl, %rax
incq %rax
retq
```
bors [Sat, 10 Jun 2017 06:50:12 +0000 (06:50 +0000)]
Auto merge of #42533 - Mark-Simulacrum:macro-parse-speed-small, r=jseyfried
Speed up expansion
This reduces duplication, thereby increasing expansion speed. Based on tests with rust-uinput, this produces a 29x performance win (440 seconds to 15 seconds). I want to land this first, since it's a minimal patch, but with more changes to the macro parsing I can get down to 12 seconds locally.
There is one FIXME added to the code that I'll keep for now since changing it will spread outward and increase the patch size, I think.
fn main() {
let tuple = (1, 2, "Asdfgh");
let zero = Test::Zero;
let one = Test::One(10);
let two = Test::Two(42, "Qwerty".to_owned());
let three = Test::Three(9000,
"Zxcvbn".to_owned(),
vec!["lorem".to_owned(), "ipsum".to_owned(), "dolor".to_owned()]);
println!(""); // breakpoint here
}
```