The documentation today does not give a complete treatment of pinning
from first principles, which appropriately describes how to design types
that use it, nor does it provide formal statements of the guarantees
users need to be aware of.
This rewrite attempts to address these in a way that makes the concept
more approachable while also making the documentation more normative.
Fix typo in docs for slice::split_once, slice::rsplit_once
This fixes a typo in the doc comments for these methods, which I tripped over while reading the docs: "If any matching elements are **resent** in the slice [...]", which is presumably meant to read **present**.
I mentioned this in #112811, the tracking issue for `slice_split_once`, and was encouraged to open a PR.
document rounding behavior of rint/nearbyint for ties
It's not possible to change the rounding mode in Rust, so these intrinsics will always behave like `roundeven`.
Rewrite Iterator::position default impl
Storing the accumulating value outside the fold in an attempt to improve code generation has shown speedups on various handwritten benchmarks, see discussion at #119551.
rustc_span: More consistent span combination operations
Also add more tests for using `tt` in addition to `ident`, and some other minor tweaks, see individual commits.
This is a part of https://github.com/rust-lang/rust/pull/119412 that doesn't yet add side tables for metavariable spans.
merge core_panic feature into panic_internals
I don't know why those are two separate features, but it does not seem intentional. This merge is useful because with https://github.com/rust-lang/rust/pull/118123, panic_internals is recognized as an internal feature, but core_panic is not -- but core_panic definitely should be internal.
Use diagnostic namespace in stdlib
This required a minor fix to have the diagnostics shown in third party crates when the `diagnostic_namespace` feature is not enabled. See 5d63f5d8d1 for details. I've opted for having a single PR for both changes as it's really not that much code. If it is required it should be easy to split up the change into several PR's.
r? `@compiler-errors`
`#[diagnostic::on_unimplemented]`
This commit replaces those `#[rustc_on_unimplemented]` attributes with
their equivalent `#[diagnostic::on_unimplemented]` where this is
supported (So no filter or any extended option)
Make offset_of field parsing use metavariable which handles any spacing
As discussed at and around comments https://github.com/rust-lang/rust/issues/106655#issuecomment-1793485081 and https://github.com/rust-lang/rust/issues/106655#issuecomment-1793774183, the current arguments to offset_of do not accept all the whitespace combinations: `0. 1.1.1` and `0.1.1. 1` are currently treated specially in `tests/ui/offset-of/offset-of-tuple-nested.rs`.
They also do not allow [forwarding individual fields as in](https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=444cdf0ec02b99e8fd5fd8d8ecb312ca)
```rust
macro_rules! off {
($a:expr) => {
offset_of!(m::S, 0. $a)
}
}
```
This PR replaces the macro arguments with `($Container:ty, $($fields:expr)+ $(,)?)` which does allow any arrangement of whitespace that I could come up with and the forwarding of fields example above.
This also allows for array indexing in the future, which I think is the last future extension to the syntax suggested in the offset_of RFC.
Tracking issue for offset_of: #106655
``@rustbot`` label F-offset_of
``@est31``
custom mir: make it clear what the return block is
Custom MIR recently got support for specifying the "unwind action", so now there's two things coming after the actual call part of `Call` terminators. That's not very self-explaining so I propose we change the syntax to imitate keyword arguments:
```
Call(popped = Vec::pop(v), ReturnTo(drop), UnwindContinue())
```
Also fix some outdated docs and add some docs to `Call` and `Drop`.
Primitive docs: fix confusing `Send` in `&T`'s list
The two lists in this document describe what traits are implemented on references when their underlying `T` also implements them. However, while it is true that `T: Send + Sync` implies `&T: Send` (which is what the sentence is trying to explain), it is confusing to have `Send` in the list because `T: Send` is not needed for that. In particular, the "also require" part may be interpreted as "both `T: Send` and `T: Sync` are required".
Instead, move `Send` back to where it was before commit 7a477869b7 ("Makes docs for references a little less confusing"), i.e. to the `&mut` list (where no extra nota is needed, i.e. it fits naturally) and move the `Sync` definition/note to the bottom as something independent.
The two lists in this document describe what traits are implemented on
references when their underlying `T` also implements them. However,
while it is true that `T: Send + Sync` implies `&T: Send` (which is
what the sentence is trying to explain), it is confusing to have `Send`
in the list because `T: Send` is not needed for that. In particular,
the "also require" part may be interpreted as "both `T: Send` and
`T: Sync` are required".
Instead, move `Send` back to where it was before commit 7a477869b7
("Makes docs for references a little less confusing"), i.e. to the `&mut`
list (where no extra nota is needed, i.e. it fits naturally) and move the
`Sync` definition/note to the bottom as something independent.
Signed-off-by: Miguel Ojeda <ojeda@kernel.org>
