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.
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`
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.
compiletest: Don't apply "emscripten" directives to `wasm32-unknown-unknown`
This special case dates all the way back to the original introduction of the `wasm32-unknown-unknown` target, in https://github.com/rust-lang/rust/pull/45905.
Either it isn't needed, in which case we should remove it, or it *is* needed, in which case we should fix the directives in any affected tests.
Note that while the intent of this code was presumably to make `//@ ignore-emscripten` also ignore tests on w32-u-u, it has the unfortunate side-effect of also causing `//@ only-emscripten` tests to *run* on w32-u-u, which is potentially very confusing.
fix(span): track unnormalized source len for dep-info
Add `unnormalized_source_len` field to track the byte length
of source files before normalization (the original length).
`unnormalized_source_len` is for writing the correct file length
to dep-info for `-Zchecksum-hash-algorithm`
Fixes https://github.com/rust-lang/rust/issues/148934
Add another *ExprWithBlock* test for `try` blocks
Looking to address this open item from rust-lang/rust#31436
> Add a test confirming that it's an `ExprWithBlock`, so works in a match arm without a comma
It turns out that rust-lang/rust#120540 addressed that one, but it made me think of this other case that probably ought to have some kind of test as well.
re-enable wasm abi test
The `wasm32-unknown-unknown` ABI has been fixed for a while now https://github.com/rust-lang/rust/issues/115666, so this test can be re-enabled and the fixme removed.
r? ``@bjorn3``
Add riscv64a23-unknown-linux-gnu to build-manifest TARGETS
This enables rustup distribution of the rust-std component for the riscv64a23-unknown-linux-gnu target
(Previous PR rust-lang/rust#148435 missed this step.)
Fix overflow-checks test for RISC-V target
The overflow-checks codegen test was failing on riscv64gc target because the FileCheck pattern did not account for ABI extension attributes. RISC-V LP64 ABI requires integer types smaller than XLEN (64-bit) to be zero-extended or sign-extended to register width.
For u8 parameters, RISC-V generates:
i8 noundef zeroext %a, i8 noundef zeroext %b
While x86_64 and aarch64 generate:
i8 noundef %a, i8 noundef %b
The original CHECK pattern only matched the format without the `zeroext` attribute, causing test failures on RISC-V.
This patch makes the zeroext attribute optional in the FileCheck pattern using `{{( zeroext)?}}`, allowing the test to pass on architectures that add ABI extension attributes (e.g., RISC-V).
Test results before fix:
- x86_64-unknown-linux-gnu: 3 passed
- aarch64-unknown-linux-gnu: 3 passed
- riscv64gc-unknown-linux-gnu: 1 passed, 2 failed
Test results after fix:
- x86_64-unknown-linux-gnu: 3 passed
- aarch64-unknown-linux-gnu: 3 passed
- riscv64gc-unknown-linux-gnu: 3 passed
tweak primitive reference docs
This is a docs-only change for primitive reference.
I noticed a typo ("safe to use at type `T`") and fixed it to read "safe to use *as* type `T`".
While reading over the whole page, I also noticed another sentence that was hard to read. I tried to improve it: feel free to comment on the wisdom of this change...
Stabilize vec_into_raw_parts
This stabilizes `Vec::into_raw_parts()` and `String::into_raw_parts()` per FCP in https://github.com/rust-lang/rust/issues/65816#issuecomment-3517630971. While this _does not_ stabilize `Vec::into_parts()`, I fixed up the examples that said they were waiting for `vec_into_raw_parts`. As `Vec::from_parts()` and `Vec::into_parts()` are covered by the same feature `box_vec_non_null`, any doctest that uses `Vec::from_parts()` can also use `Vec::into_parts()` (and same for allocator-aware versions).
Closesrust-lang/rust#65816
``@rustbot`` modify labels: +T-libs-api
Micro-optimize rustdoc search index parsing
This should pre-allocate the correct size for the `slot` vec. Not sure how much of a difference it'll make, but let's see.
Add `unnormalized_source_len` field to track the byte length
of source files before normalization (the original length).
`unnormalized_source_len` is for writing the correct file length
to dep-info for `-Zchecksum-hash-algorithm`
