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.
Exhaustiveness: remove `Matrix.wildcard_row`
To compute exhaustiveness, we check whether an extra row with a wildcard added at the end of the match expression would be reachable. We used to store an actual such row of patterns in the `Matrix`, but it's a bit redundant since we know it only contains wildcards. It was kept because we used it to get the type of each column (and relevancy). With this PR, we keep track of the types (and relevancy) directly.
This is part of me splitting up https://github.com/rust-lang/rust/pull/119581 for ease of review.
r? `@compiler-errors`
in particular, this makes the `c` feature for compiler-builtins an explicit opt-in, rather than silently detected by whether `llvm-project` is checked out on disk.
exposing this is necessary because the `cc` crate doesn't support cross-compiling to MSVC, and we want people to be able to run `x check --target foo` regardless of whether they have a c toolchain available.
this also uses the new option in CI, where we *do* want to optimize compiler_builtins.
the new option is off by default for the `dev` channel and on otherwise.
mark vec::IntoIter pointers as `!nonnull`
This applies the same NonNull optimizations to `vec::IntoIter` as #113344 did for `slice::Iter`
[Godbolt](https://rust.godbolt.org/z/n1cTea718) showing the test IR on current nightly, note the absence of `!nonnull` on the loads.
r? `@scottmcm`
Rollup of 6 pull requests
Successful merges:
- #119252 (rustc_mir_transform: Enforce `rustc::potential_query_instability` lint)
- #119548 (Use the current target instead of iterating over all targets)
- #119656 (document rounding behavior of rint/nearbyint for ties)
- #119657 (Fix typo in docs for slice::split_once, slice::rsplit_once)
- #119666 (Populate `yield` and `resume` types in MIR body while body is being initialized)
- #119679 (Ask for rustc version in diagnostic reports, remind users to update their toolchain)
r? `@ghost`
`@rustbot` modify labels: rollup
Ask for rustc version in diagnostic reports, remind users to update their toolchain
IDK why we don't ask for rustc toolchain when filing diagnostic issues. Diagnostics are sometimes very dramatically affected by compiler version, and users may report old diagnostic issues that were fixed by subsequent rustc versions that they have yet to update to.
For example, #119678 was made a bit more difficult to triage due to the template not asking the issuer to report their rustc version.
Populate `yield` and `resume` types in MIR body while body is being initialized
I found it weird that we went back and populated these types *after* the body was constructed. Let's just do it all at once.
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`.
Use the current target instead of iterating over all targets
Since we already iterate through targets in StepDescription::maybe_run, there is no need to iterate targets again in the install step for std.
Compared the results before and after applying the changes to install step of std, and there were no differences.
```sh
~/devspace/.other/rustc-builds $ sha256sum ./old/usr/local/lib/rustlib/manifest-rust-std-x86_64-*
c2ea86fc25ffac87b0b135f31ba9644ad97549da4c050c3921b437d1e18285fd ./old/usr/local/lib/rustlib/manifest-rust-std-x86_64-pc-windows-gnu
d2f1081a779962e2cbc27f53191783d13428abd0964465547af78ce34c7251dd ./old/usr/local/lib/rustlib/manifest-rust-std-x86_64-unknown-linux-gnu
~/devspace/.other/rustc-builds $ sha256sum ./new/usr/local/lib/rustlib/manifest-rust-std-x86_64-*
c2ea86fc25ffac87b0b135f31ba9644ad97549da4c050c3921b437d1e18285fd ./new/usr/local/lib/rustlib/manifest-rust-std-x86_64-pc-windows-gnu
d2f1081a779962e2cbc27f53191783d13428abd0964465547af78ce34c7251dd ./new/usr/local/lib/rustlib/manifest-rust-std-x86_64-unknown-linux-gnu
```
Fixes#119533
rustc_mir_transform: Enforce `rustc::potential_query_instability` lint
Stop allowing `rustc::potential_query_instability` on all of rustc_mir_transform and instead allow it on a case-by-case basis if it is safe to do so. In this particular crate, all instances were safe to allow.
Part of https://github.com/rust-lang/rust/issues/84447 which is E-help-wanted.
Run Miri and mir-opt tests without a target linker
Normally, we need a linker for the target to build the standard library. That's only because `std` declares crate-type lib and dylib; building the dylib is what creates a need for the linker.
But for mir-opt tests (and for Miri) we do not need to build a `libstd.so`. So with this PR, when we build the standard library for mir-opt tests, instead of `cargo build` we run `cargo rustc --crate-type=lib` which overrides the configured crate types in `std`'s manifest.
I've also swapped in what seems to me a better hack than `BOOTSTRAP_SKIP_TARGET_SANITY` to prevent cross-interpreting with Miri from checking for a target linker and expanded it to mir-opt tests too. Whether it's actually better is up to a reviewer.
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.
