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).
We don't want to guarantee that `Instant::now() != Instant::now()` is
always true since that depends on the speed of the processor and the
resolution of the clock.
#[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.
Mark it with the `unreachable` feature and put it into the `mem` module.
This is a pretty straight-forward API that can already be simulated in
stable Rust by using `transmute` to create an uninhabited enum that can
be matched.
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
The spans previously encoded only span the first token after the opening
brace, up to the closing brace of inline `mod` declarations. Thus, when
examining exports from an external crate, the spans don't include the
header of inline `mod` declarations.
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.
Part of #29365.
* Added paragraph adapted from API guidelines that operator implementations
should be unsurprising
* Modified Point example to be more clear when just reading it
Part of #29365.
* Strenghtened summary/explanation split, making phrasings more parallel
* Added links throughout
* Fixed some example formatting & removed extraneous `fn main()`s (or hid
then when needed because of `#![features]`.
* Emphasized note on `RangeFrom`'s `Iterator` implementation
* Added summary sentences to (unstable) `contains` methods
Part of #29365.
* Moved explanations out of Examples section and expanded on them.
* Made the super-/subtrait relationships more explicit.
* Added links to the other traits, TRPL and the nomicon where appropriate
* Changed method summaries to be in 3rd person singular
* General copyediting
