compiletest: Remove the "wasm32-bare" alias for `wasm32-unknown-unknown`
- Follow-up to https://github.com/rust-lang/rust/pull/148969
This "wasm32-bare" alias, understood by compiletest's `//@ ignore-wasm32-bare` and `//@ only-wasm32-bare` directives, dates all the way back to the original introduction of the `wasm32-unknown-unknown` target in https://github.com/rust-lang/rust/pull/45905.
But there is no compelling reason to use an alias instead of the full target name.
r? jieyouxu
triagebot: remove jsha from notifications for rustdoc HTML
See https://github.com/rust-lang/team/pull/2083 - I'm moving to alumni status for rustdoc and no longer need these notifications.
compiletest: Avoid race condition in file deletion
Fixesrust-lang/rust#149003
There is a TOCTOU when multiple threads attempt to delete the same file. Instead of pre-checking if the file exists, we can simply ignore `NotFound` errors.
Tweak Motor OS linker preset, fix `remote-test-server` for Motor OS
Had to tweak linking options in target spec to make it work (see https://github.com/moturus/motor-os/issues/46).
Abi compatibility test cleanup
r? `@jieyouxu`
- moves `NonNull` (and some friends) into `minicore.rs` so it can be re-used.
- tests the abi compatibility of a couple more targets. It's useful to have a comprehensive overview of all ABIs that rust has some amount of support for, e.g. testing for c-variadic or guaranteed tail calls (cc https://github.com/rust-lang/rust/issues/148748)
add note to `lines` docs about empty str behavior
This pull request adds a short note to the documentation for `str::lines` that describes the behavior of the resulting iterator when called on an empty string. I tripped over this a few days ago because I thought (incorrectly) that the iterator would return a single line with an empty string. I don't doubt that the actual behavior (return no lines) is the correct behavior, but in the absence of explicit documentation describing it, I came to the wrong conclusion about it and maybe others will too. If this is so obvious as to be not worth including, I'm happy to withdraw the pull request! Thanks for taking a look.
Error if an autodiff user does not set lto=fat
Based on your feedback, I started to provide a nice error message for a lack of `lto=fat`, instead of us forcing it.
In a next step, we should replace `RUSTFLAGS="-Zautodiff=Enable"` with another Cargo.toml setting, as discussed here: https://github.com/rust-lang/rust/issues/147487#issuecomment-3446558644
As another improvement, we should also figure out why rlib builds do not properly obey the fat=lto setting.
```````@bjorn3```````
add larger test for `proc_macro` `FromStr` implementations
Currently, there are only few tests that check the output of `TokenStream::from_str` and `Literal::from_str` (which is somewhat understandable as the rustc implementation just delegates these calls to the parser). In preparation for both the standalone backend (rust-lang/rust#130856) which will probably need to reimplement this logic as well as for removing panics from these functions (rust-lang/rust#58736), this PR adds a test which shows the various messy ways of how these functions report errors and the return values for successful parses.
Followup PRs such as rust-lang/rust#147859 will change more and more of these "diagnostic + error"s into `LexErrors`.
The test structure with the extra module is used to allow reusing it later easily for the standalone backend.
use funnel shift as fallback impl for rotating shifts
That lets us remove this gnarly implementation from Miri and const-eval.
However, `rotate_left`/`rotate_right` are stable as const fn, so to do this we have to `rustc_allow_const_fn_unstable` a bunch of const trait stuff. Is that a bad idea? Cc `@oli-obk` `@fee1-dead`
rust-installer/install-template.sh: improve efficiency, step 1.
This round replaces repetitive pattern matching in the inner loop of this script using grep (which causes a `fork()` for each test) with built-in pattern matching in the Bourne shell using the `case` / `esac` construct.
This in reference to
https://github.com/rust-lang/rust/issues/80684
and is a separated-out request from
https://github.com/rust-lang/rust-installer/pull/111
which apparently never got any review.
The forthcoming planned "step 2" change builds on top of this change, and replaces the inner-loops needless uses of `sed` (which again causes a `fork()` for each instance) with the suffix removal constructs from the Bourne shell. Since this change touches lots of the same lines this change does, that pull request cannot be submitted before this one is accepted.
Hopefully this first step is less controversial than the latter change.
When GenMC says that an execution should not be explored further,
Miri needs to know why (e.g., so that it returns an appropriate
exit value). Until now, some (erroneous) heuristics were used
for that.
This commit changes the Miri/GenMC API to check the scheduling
result of GenMC (that now reflects the "stop type").
The new error-reporting mechanism of GenMC changed its public API.
This commit adjusts the Miri interface accordingly (all driver
calls need an extra argument that represents possible debugging
information).
GenMC v0.14.1 does not throw an error internally if the config
is invalid, but rather returns an appropriate error value.
This commit has setup code in Miri check the returned value,
and exit if there are any errors.
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#148703 (Use `overflow_checks` intrinsic so `IterRangeFrom` yields MAX before panicking in debug)
- rust-lang/rust#148881 (use `cfg_select!` to pick assembly in codegen test)
- rust-lang/rust#148911 (Make flags from `*FLAGS*` (such as `RUSTFLAGS`) env. vars. have precedence over flags set by bootstrap)
- rust-lang/rust#148914 (fix incorrect import in `std_detect` on `aarch64-unknown-openbsd`)
- rust-lang/rust#148971 (Document Error::{new,other} as to be avoided in pre_exec)
- rust-lang/rust#148983 (Use rustc target metadata for build-manifest target lists)
- rust-lang/rust#148995 (add must_use to extract_if methods)
r? `@ghost`
`@rustbot` modify labels: rollup
add must_use to extract_if methods
Also, mention the `.for_each(drop)` pattern in the documentation. One can't always use `retain` with a negated predicate as that does not have a range argument.
r? `@the8472`
Use rustc target metadata for build-manifest target lists
This ensures that as long as the target metadata is updated to reflect the current state (tier 3 vs 1/2, host toolchain support), the manifest will also be updated. This avoids an extremely common 'oops' when we move targets between tiers.
This mostly removes a bunch of tier 3 targets from manifests. I didn't spot check against produced artifacts but given that they are tier 3 it's probably reasonable to leave it as-is and bug reporters can fix the target metadata in rustc (or we can stop producing artifacts).
Follow-up work would ideally lint the artifact list as part of nightly/beta/stable builds as well, but for now this is simple and hopefully removes at common source of extra PRs when modifying targets.
Manifest list delta:
```diff
--- old
+++ new
-host:i686-apple-darwin
-host:mips-unknown-linux-gnu
-host:mips64-unknown-linux-gnuabi64
-host:mips64el-unknown-linux-gnuabi64
-host:mipsel-unknown-linux-gnu
-host:mipsisa32r6-unknown-linux-gnu
-host:mipsisa32r6el-unknown-linux-gnu
-host:mipsisa64r6-unknown-linux-gnuabi64
-host:mipsisa64r6el-unknown-linux-gnuabi64
-target:aarch64-unknown-hermit
-target:aarch64-unknown-managarm-mlibc
-target:aarch64-unknown-redox
-target:amdgcn-amd-amdhsa
-target:arm64e-apple-darwin
-target:arm64e-apple-ios
-target:arm64e-apple-tvos
-target:armebv7r-none-eabi
-target:armebv7r-none-eabihf
-target:armv7s-apple-ios
-target:bpfeb-unknown-none
-target:bpfel-unknown-none
-target:csky-unknown-linux-gnuabiv2
-target:csky-unknown-linux-gnuabiv2hf
-target:i386-apple-ios
-target:i586-unknown-redox
-target:i686-apple-darwin
-target:loongarch32-unknown-none
-target:loongarch32-unknown-none-softfloat
-target:m68k-unknown-linux-gnu
-target:m68k-unknown-none-elf
-target:mips-mti-none-elf
-target:mips-unknown-linux-gnu
-target:mips-unknown-linux-musl
-target:mips64-unknown-linux-gnuabi64
-target:mips64-unknown-linux-muslabi64
-target:mips64el-unknown-linux-gnuabi64
-target:mips64el-unknown-linux-muslabi64
-target:mipsel-mti-none-elf
-target:mipsel-unknown-linux-gnu
-target:mipsel-unknown-linux-musl
-target:mipsisa32r6-unknown-linux-gnu
-target:mipsisa32r6el-unknown-linux-gnu
-target:mipsisa64r6-unknown-linux-gnuabi64
-target:mipsisa64r6el-unknown-linux-gnuabi64
-target:riscv32gc-unknown-linux-gnu
-target:riscv32im-risc0-zkvm-elf
-target:riscv32ima-unknown-none-elf
-target:riscv64gc-unknown-hermit
-target:riscv64gc-unknown-linux-musl
-target:riscv64gc-unknown-managarm-mlibc
-target:sparc-unknown-none-elf
-target:x86_64-unikraft-linux-musl
-target:x86_64-unknown-hermit
-target:x86_64-unknown-managarm-mlibc
```
fix incorrect import in `std_detect` on `aarch64-unknown-openbsd`
fixes https://github.com/rust-lang/rust/issues/148898
In https://github.com/rust-lang/rust/pull/147024 the module structure of `std_detect` for `openbsd` was changed which invalidated this `super::` usage.
I've now tested that `std_detect` builds (or well, checks, because I don't have the right linkers) with `aarch64-unknown-openbsd` and `powerpc64-unknown-openbsd`.
Make flags from `*FLAGS*` (such as `RUSTFLAGS`) env. vars. have precedence over flags set by bootstrap
Before this PR extra flags from env variables like `RUSTFLAGS` had lower precedence than bootstrap flags. This PR changes that, and tus makes overriding flags passed to the compiler easier and more reliable.
This is technically a breaking change — but it only affects people using these env variables.
This change was [discussed on zulip](https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/Precedence.20of.20RUSTFLAGS.20in.20bootstrap/with/554903280) by members of bootstrap team.
r? `@Kobzol`
Ralf Jung