Document the behaviour of infinite iterators on potentially-computable methods
It’s not entirely clear from the current documentation what behaviour
calling a method such as `min` on an infinite iterator like `RangeFrom`
is. One might expect this to terminate, but in fact, for infinite
iterators, `min` is always nonterminating (at least in the standard
library). This adds a quick note about this behaviour for clarification.
Add fetch_nand to atomics
I think this is all fine but I have little familiarity with the atomic code (or libcore in general) so I may have accidentally done something wrong here...
cc #13226 (the tracking issue)
`match`ing on an `Option<Ordering>` seems cause some confusion for LLVM; switching to just using comparison operators removes a few jumps from the simple `for` loops I was trying.
Implement TrustedLen for Take<Repeat> and Take<RangeFrom>
This will allow optimization of simple `repeat(x).take(n).collect()` iterators, which are currently not vectorized and have capacity checks.
This will only support a few aggregates on `Repeat` and `RangeFrom`, which might be enough for simple cases, but doesn't optimize more complex ones. Namely, Cycle, StepBy, Filter, FilterMap, Peekable, SkipWhile, Skip, FlatMap, Fuse and Inspect are not marked `TrustedLen` when the inner iterator is infinite.
Previous discussion can be found in #47082
r? @alexcrichton
Add filtering options to `rustc_on_unimplemented`
- Add filtering options to `rustc_on_unimplemented` for local traits, filtering on `Self` and type arguments.
- Add a way to provide custom notes.
- Tweak binops text.
- Add filter to detect wether `Self` is local or belongs to another crate.
- Add filter to `Iterator` diagnostic for `&str`.
Partly addresses #44755 with a different syntax, as a first approach. Fixes#46216, fixes#37522, CC #34297, #46806.
Fix info about generic impls in AsMut docs
This text was copy-pasted from the `AsRef` docs to `AsMut`, but needed some additional adjustments for correctness.
Because the last item needs special handling, it seems that LLVM has trouble canonicalizing the loops in external iteration. With the override, it becomes obvious that the start==end case exits the loop (as opposed to the one *after* that exiting the loop in external iteration).
Turn `type_id` into a constant intrinsic
https://github.com/rust-lang/rust/issues/27745
The method `get_type_id` in `Any` is intended to support reflection. It's currently unstable in favor of using an associated constant instead. This PR makes the `type_id` intrinsic a constant intrinsic, the same as `size_of` and `align_of`, allowing `TypeId::of` to be a `const fn`, which will allow using an associated constant in `Any`.
copy_nonoverlapping example: Fixed typo
The comment referred to a variable using an incorrect name. (it has probably been renamed since the comment was written, or the comment was copied elsewhere - I noted the example in libcore has the `tmp` name for the temporary variable.)
The comment referred to a variable using an incorrect name. (it has probably been renamed since the comment was written, or the comment was copied elsewhere - I noted the example in libcore has the `tmp` name for the temporary variable.)
- filter error on the evaluated value of `Self`
- filter error on the evaluated value of the type arguments
- add argument to include custom note in diagnostic
- allow the parser to parse `Self` when processing attributes
- add custom message to binops
The current `f32|f64.to_degrees` implementation uses a division to calculate 180/π, which causes a loss of precision. Using a constant is still not perfect (implementing a maximally-precise algorithm would come with a high performance cost), but improves precision with a minimal change.
Use the slice length to hint the optimizer about iter.position result
Using the len of the iterator doesn't give the same result.
That's also why we can't generalize it to all TrustedLen iterators.
Problem demo: https://godbolt.org/g/MXg2ae
Fix demo: https://godbolt.org/g/P8q5aZ
Second attempt of #47333
Third attempt of #45501Fixes#45964
Make core::ops::Place an unsafe trait
Consumers of `Place` would reasonably expect that the `pointer` function returns a valid pointer to memory that can actually be written to.
