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.
improve [`cast_sign_loss`], to skip warning on always positive expressions
fixes: #11642
changelog: improve [`cast_sign_loss`] to skip warning on always positive expressions
Turns out this is change became quite big, and I still can't cover all the cases, like method calls such as `POSITIVE_NUM.mul(POSITIVE_NUM)`, or `NEGATIVE_NUM.div(NEGATIVE_NUM)`... but well, if I do, I'm scared that this will goes forever, so I stopped, unless it needs to be done, lol.
Do not suggest `[T; n]` instead of `vec![T; n]` if `T` is not `Copy`
changelog: [`useless_vec`]: do not suggest replacing `&vec![T; N]` by `&[T; N]` if `T` is not `Copy`
Fix#11958
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.
Extend `map_clone` lint to also work on non-explicit closures
I found it weird that this case was not handled by the current line so I added it. The only thing is that I don't see an obvious way to infer the current type to determine if it's copyable or not, so for now I always suggest `cloned` and I added a FIXME.
r? `@llogiq`
changelog: Extend `map_clone` lint to also work on non-explicit closures
The output is produced by printf from C code in these cases, and printf prints in text mode, which means `\n` will be printed as `\r\n` on Windows.
In --bless mode the new output with `\r\n` will replace expected output in `tests/run-make/raw-dylib-*\output.txt` files, which use \n, always resulting in dirty files in the repo.
Strip lld-wrapper binaries
This cuts down on the amount of data we need to ship and users need to keep on disk for each Rust toolchain. As noted in the added comment, there's not much going on in these executables, so the added benefit of symbols and debuginfo isn't large, while the cost is not insignificant.
This takes each of the binaries (we store 4 identical copies under different names) from 3.7MB to 384KB.
Remove ignore-stage1 that was added when changing error count msg
The bootstrap bump has happened, so the bootstrap compiler now contains the new diagnostic.
this was added in #118138
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.
