It's more pleasing to use the inner-attribute syntax (`#!` rather than
`#`) in the error message, as that is how `feature` attributes in
particular will be declared (as they apply to the entire crate).
#[must_use] for functions
This implements [RFC 1940](https://github.com/rust-lang/rfcs/pull/1940).
The RFC and discussion thereof seem to suggest that tagging `PartialEq::eq` and friends as `#[must_use]` would automatically lint for unused comparisons, but it doesn't work out that way (at least the way I've implemented it): unused `.eq` method calls get linted, but not `==` expressions. (The lint operates on the HIR, which sees binary operations as their own thing, even if they ultimately just call `.eq` _&c._.)
What do _you_ think??
Resolves#43302.
Add an overflow check in the Iter::next() impl for Range<_> to help with vectorization.
This helps with vectorization in some cases, such as (0..u16::MAX).collect::<Vec<u16>>(),
as LLVM is able to change the loop condition to use equality instead of less than and should help with #43124. (See also my [last comment](https://github.com/rust-lang/rust/issues/43124#issuecomment-319098625) there.) This PR makes collect on ranges of u16, i16, i8, and u8 **significantly** faster (at least on x86-64 and i686), and pretty close, though not quite equivalent to a [manual unsafe implementation](https://is.gd/nkoecB). 32 ( and 64-bit values on x86-64) bit values were already vectorized without this change, and they still are. This PR doesn't seem to help with 64-bit values on i686, as they still don't vectorize well compared to doing a manual loop.
I'm a bit unsure if this was the best way of implementing this, I tried to do it with as little changes as possible and avoided changing the step trait and the behavior in RangeFrom (I'll leave that for others like #43127 to discuss wider changes to the trait). I tried simply changing the comparison to `self.start != self.end` though that made the compiler segfault when compiling stage0, so I went with this method instead for now.
As for `next_back()`, reverse ranges seem to optimise properly already.
Update the list of confusable characters
Also reorder and space the list to make it clearer for futures updates
and to come closer to the original list.
This was tedious but somewhat rewarding!
Thanks @est31 for the instructions.
Fixes#43629.
r? @est31
make `for_all_relevant_impls` O(1) again
A change in #41911 had made `for_all_relevant_impls` do a linear scan over
all impls, instead of using an HashMap. Use an HashMap again to avoid
quadratic blowup when there is a large number of structs with impls.
I think this fixes#43141 completely, but I want better measurements in
order to be sure. As a perf patch, please don't roll this up.
r? @eddyb
beta-nominating because regression
A change in #41911 had made `for_all_relevant_impls` do a linear scan over
all impls, instead of using an HashMap. Use an HashMap again to avoid
quadratic blowup when there is a large number of structs with impls.
I think this fixes#43141 completely, but I want better measurements in
order to be sure. As a perf patch, please don't roll this up.
[libstd_unicode] Change UNICODE_VERSION to use u32
Looks like there's no strong reason to keep these values at `u64`.
With the current plans for the Unicode Standard, `u8` should be enough for the next 200 years. To stay on the safe side, I'm using `u16` here. I don't see a reason to go with anything machine-dependent/more-efficient.
Update libc to 0.2.29
Cargo pulls in libc from crates.io for a number of dependencies, but 0.2.27 is too old to work properly with Solaris. In particular, it needs the change to make Solaris' `PTHREAD_PROCESS_PRIVATE` a 16-bit integer.
Cargo pulls in libc from crates.io for a number of dependencies, but
0.2.27 is too old to work properly with Solaris. In particular, it
needs the change to make Solaris' PTHREAD_PROCESS_PRIVATE a 16-bit
integer.
rustc::middle::dataflow - visit the CFG in RPO
We used to propagate bits in node-id order, which sometimes caused an
excessive number of iterations, especially when macros were present. As
everyone knows, visiting the CFG in RPO bounds the number of iterators
by 1 plus the depth of the most deeply nested loop (times the height of
the lattice, which is 1).
I have no idea how this affects borrowck perf in the non-worst-case, so it's probably a good idea to not roll this up so we can see the effects.
Fixes#43704.
r? @eddyb
We used to propagate bits in node-id order, which sometimes caused an
excessive number of iterations, especially when macros were present. As
everyone knows, visiting the CFG in RPO bounds the number of iterators
by 1 plus the depth of the most deeply nested loop (times the height of
the lattice, which is 1).
Fixes#43704.
de-orphan extended information
Bizarrely, librustc_passes, librustc_plugin, librustc_mir, and libsyntax [weren't getting their error explanations registered](https://github.com/rust-lang/rust/issues/35284) (leaving _several_ error codes absent from [the index](https://doc.rust-lang.org/nightly/error-index.html) and `--explain`). This surfaced a few latent doctest failures that were fixed where readily possible and ignored (with a recorded excuse) if not.
Also, we don't issue E0563 anymore.
r? @GuillaumeGomez
The sole appearance of this code was deleted in 6383de15; the existing practice
in these cases seems to be to comment out its mention in
`register_diagnostics!`.
After repatriating error explanations to the global registry, some lurking
doctest failures surfaced and needed to be chased down. Sadly, a few doctests
needed to be ignored due to a not-yet-understood regression in the doctest
`compile_fail` functionality (filed #43707).
Also reorder and space the list to make it clearer for futures updates
and to come closer to the original list.
Thanks @est31 for the instructions.
Fixes#43629.
r? @est31
Optimize initialization of arrays using repeat expressions
This PR was inspired by [this thread](https://www.reddit.com/r/rust/comments/6o8ok9/understanding_rust_performances_a_newbie_question/) on Reddit.
It tries to bring array initialization in the same ballpark as `Vec::from_elem()` for unoptimized builds.
For optimized builds this should relieve LLVM of having to figure out the construct we generate is in fact a `memset()`.
To that end this emits `llvm.memset()` when:
* the array is of integer type and all elements are zero (`Vec::from_elem()` also explicitly optimizes for this case)
* the array elements are byte sized
If the array is zero-sized initialization is omitted entirely.
