Don't `alloca` just to look at a discriminant
Today we're making LLVM do a bunch of extra work when you match on trivial stuff like `Option<bool>` or `ControlFlow<u8>`.
This PR changes that so that simple types like `Option<u32>` or `Result<(), Box<Error>>` can stay as `OperandValue::ScalarPair` and we can still read the discriminant from them, rather than needing to write them into memory to have a `PlaceValue` just to get the discriminant out.
Fixes#137503
Add a .bss-like scheme for encoded const allocs
This check if all bytes are zero feel like it should be too slow, and instead we should have a flag that we track, but that seems hard. Let's see how this perfs first.
Also we can probably stash the "it's all zero actually" flag inside one of the other struct members that's already not using an entire byte. This optimization doesn't fire all that often, so it's possible that by sticking it in the varint length field, this PR actually makes rmeta size worse.
Do not register `Self: AutoTrait` when confirming auto trait (in old solver)
Every built-in auto impl for a trait goal like `Ty: Auto` immediately registers another obligation of `Ty: Auto` as one of its nested obligations, leading to us stressing the cycle detection machinery a lot more than we need to. This is because all traits have a `Self: Trait` predicate.
To fix this, remove the call to `impl_or_trait_obligations` in `vtable_auto_impl`, since auto traits do not have where clauses.
r? lcnr
Calculate predecessor count directly
Avoid allocating a vector of small vectors merely to determine how many
predecessors each basic block has.
Additionally use u8 and saturating operations. The pass only needs to
distinguish between [0..1] and [2..].
Use sa_sigaction instead of sa_union.__su_sigaction for AIX
Revert test cases to use `sa_sigaction` instead of `sa_union.__su_sigaction`, now that the `libc` crate implementation for AIX defines `sa_sigaction` as a direct member of `struct sigaction`, aligning it with implementations on other similar platforms. ([[AIX] Use sa_sigaction instead of the union](https://github.com/rust-lang/libc/pull/4250)).
Rustdoc: remove a bunch of @ts-expect-error from main.js
r? ```````@notriddle```````
Most remaining instances of ````````@ts-expect-error```````` in `search.js` and `main.js` are some sort of unchecked assertion, most of them involving nullibility, and we have yet to decide on how to handle these.
Disentangle `ForwardGenericParamBan` and `ConstParamTy` ribs
In #137617, the `ConstParamTy` rib was adjusted to act kinda like the `ForwardGenericParamBan`. However, this means that it no longer served its purpose banning generics from *parent items*. Although we still are checking for param type validity using the `ConstParamTy_` trait, which means that we weren't accepting code we shouldn't, I think it's a bit strange for us not to be rejecting code like this during *resolution* and instead letting these malformed const generics leak into the type system:
```rust
trait Foo<T> {
fn bar<const N: T>() {}
}
```
This PR does a few things:
1. Introduce a `ForwardGenericParamBanReason` enum, and start using the `ForwardGenericParamBan` rib to ban forward-declared params in const tys when `generic_const_parameter_types` is enabled.
2. Start using the `ConstParamTy` rib to ban *all* generics when `generic_const_parameter_types` is disabled.
3. Improve the diagnostics for both of the cases above, and for forward-declared params in parameter defaults too :3
r? `@BoxyUwU` or reassign
Support rmeta inputs for --crate-type=bin --emit=obj
This already works for --emit=metadata, but is possible anytime we're not linking.
Tests:
- `rmeta_bin` checks we're not changing --emit=link (already passes)
- `rmeta_bin-pass` tests the new behavior for --emit=obj (would fail today) and also --emit=metadata which isn't changing
Update bootstrap to edition 2024
The stage0 compiler now supports edition 2024, so we can update bootstrap to it. I manually reviewed all the changes from `cargo fix --edition` and reverted most of them (`if let` -> `matches` changes and two unneeded usages of `use <>`).
r? `@onur-ozkan`
try-job: dist-x86_64-msvc
strip `-Wlinker-messages` wrappers from `rust-lld` rmake test
The `tests/run-make/rust-lld` rmake test is failing locally on my M1, due to linker messages being in a different shape than the test expects: it asserts that the LLD version is the first linker message, which is seemingly not always the case on osx I guess.
```console
thread 'main' panicked at /Users/lqd/rust/lqd-rust/tests/run-make/rust-lld/rmake.rs:24:5:
the LLD version string should be present in the output logs:
warning: linker stderr: rust-lld: directory not found for option -L/usr/local/lib
LLD 20.1.0 (https://github.com/rust-lang/llvm-project.git 1c3bb96fdb6db7b8e8f24edb016099c223fdd27e)
Library search paths:
/Users/lqd/rust/lqd-rust/build/aarch64-apple-darwin/test/run-make/rust-lld/rmake_out
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/lib
Framework search paths:
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks
```
This PR normalizes away the `-Wlinker-messages` wrappers around the linker output, to remove the requirement that the linker version is the first linker message / is prefixed with the warning wrapper in the regex.
(also another strange thing to explain the pre-existing regex: it seems the LLD version is sometimes output on stderr sometimes on stdout cool stuff)
We could do this for the other lld rmake tests, but they're only enabled on x64 linux so less likely to have random linker messages appearing without anyone noticing.
Allow bounds checks when enumerating `IndexSlice` to be elided
Without this hint, each loop iteration has to separately bounds check the index. See https://godbolt.org/z/zrfPY4Ten for an example.
This is technically a behaviour change, but only in cases where the compiler is going to crash anyways.
Continuing the work from #137350.
Removes the unused methods: `expect_variant`, `expect_field`,
`expect_foreign_item`.
Every method gains a `hir_` prefix.
Add `#[define_opaques]` attribute and require it for all type-alias-impl-trait sites that register a hidden type
Instead of relying on the signature of items to decide whether they are constraining an opaque type, the opaque types that the item constrains must be explicitly listed.
A previous version of this PR used an actual attribute, but had to keep the resolved `DefId`s in a side table.
Now we just lower to fields in the AST that have no surface syntax, instead a builtin attribute macro fills in those fields where applicable.
Note that for convenience referencing opaque types in associated types from associated methods on the same impl will not require an attribute. If that causes problems `#[defines()]` can be used to overwrite the default of searching for opaques in the signature.
One wart of this design is that closures and static items do not have generics. So since I stored the opaques in the generics of functions, consts and methods, I would need to add a custom field to closures and statics to track this information. During a T-types discussion we decided to just not do this for now.
fixes#131298
Remove unnecessary `[lints.rust]` sections.
`bootstrap` and `llvm_enzyme` are now both in the extra `check-cfg` list in bootstrap, so they doesn't need to be handled explicitly in `Cargo.toml` files.
r? ```@jieyouxu```
Allow specifying glob patterns for try jobs
This PR modifies the `try-job` lookup logic to allow glob patterns. So you can e.g. request all MSVC-related jobs with `try-job: *msvc*`.
Best reviewed commit by commit.
r? ``````@marcoieni``````
try-job: `*msvc*`
[AIX] Fix hangs during testing
Fixes all current test hangs experienced during CI runs.
1. ipv6 link-local (the loopback device) gets assigned an automatic zone id of 1, causing the assert to fail and hang in `library/std/src/net/udp/tests.rs`
2. Const alloc does not fail gracefully
3. Debuginfo test has problem with gdb auto load safe path
Speed up target feature computation
The LLVM backend calls `LLVMRustHasFeature` twice for every feature. In short-running rustc invocations, this accounts for a surprising amount of work.
r? `@bjorn3`
Update cargo
22 commits in 2622e844bc1e2e6123e54e94e4706f7b6195ce3d..ab1463d632528e39daf35f263e10c14cbe590ce8
2025-02-28 12:33:57 +0000 to 2025-03-08 01:45:05 +0000
- test: redact host target when comparing CARGO_ENV path (rust-lang/cargo#15279)
- feat: add completions for install --path (rust-lang/cargo#15266)
- fix(package): report lockfile / workspace manifest is dirty (rust-lang/cargo#15276)
- feat(tree): Add `--depth public` behind `-Zunstable-options` (rust-lang/cargo#15243)
- Don't use `$CARGO_BUILD_TARGET` in `cargo metadata` (rust-lang/cargo#15271)
- feat: show extra build description from bootstrap (rust-lang/cargo#15269)
- Upgrade to `rustc-stable-hash v0.1.2` (rust-lang/cargo#15268)
- fix: Respect --frozen everywhere --offline or --locked is accepted (rust-lang/cargo#15263)
- feat(tree): Color the output (rust-lang/cargo#15242)
- fix(vendor): dont remove non-cached source (rust-lang/cargo#15260)
- docs: lockfile is always included since 1.84 (rust-lang/cargo#15257)
- Remove `Cargo.toml` from `package.include` in example (rust-lang/cargo#15253)
- Small cleanup: remove unneeded result (rust-lang/cargo#15256)
- Fix typo in build-scripts.md (rust-lang/cargo#15254)
- chore(deps): update rust crate pulldown-cmark to 0.13.0 (rust-lang/cargo#15250)
- chore(deps): update compatible (rust-lang/cargo#15249)
- feat(cli): forward bash completions of third party subcommands (rust-lang/cargo#15247)
- feat: add completions for `--lockfile-path` (rust-lang/cargo#15238)
- fix: reset $CARGO if the running program is real `cargo[.exe]` (rust-lang/cargo#15208)
- Get all members as `available targets` even though default-members was specified. (rust-lang/cargo#15199)
- refactor: control byte display precision with std::fmt options (rust-lang/cargo#15246)
- fix(package): Ensure we can package directories ending with '.rs' (rust-lang/cargo#15240)
Change TaskDeps to start preallocated with 128 capacity
This is a tiny change that makes `TaskDeps::read_set` start preallocated with capacity for 128 elements.
From local profiling, it looks like `TaskDeps::read_set` is one of the most-often resized hash-sets in `rustc`.
add `tool::CargoClippy` and `tool::Cargofmt` binary to target sysroot
When running `x build clippy`, we expect `stage1-tool-bin/cargo-clippy` and `stage2/bin/cargo-clippy` to be the same, but they aren't. This happens because `tool::CargoClippy` doesn't place its binary in the `stage2` directory. As a result, `stage1-tool-bin/cargo-clippy` comes from `tool::CargoClippy`, while `stage2/bin/cargo-clippy` comes from `tool::Cargo`. Same applies for `tool::Cargofmt`.
This PR fixes the issue by adding `tool::CargoClippy` and ``tool::Cargofmt`` binaries to the expected sysroot and makes sure both directories share the same binary.
To test this, run `x build --stage 2 compiler clippy rustfmt`, link the stage2 sysroot with rustup, and then call `cargo +stage2 fmt` and `cargo +stage2 clippy` on any rust project (it wouldn't work without this PR).
Don't re-`assume` in `transmute`s that don't change niches
I noticed in nightly 2025-02-21 that `transmute` is emitting way more `assume`s than necessary for newtypes.
For example, the three transmutes in <https://rust.godbolt.org/z/fW1KaTc4o> emits
```rust
define noundef range(i32 1, 0) i32 `@repeatedly_transparent_transmute(i32` noundef range(i32 1, 0) %_1) unnamed_addr {
start:
%0 = sub i32 %_1, 1
%1 = icmp ule i32 %0, -2
call void `@llvm.assume(i1` %1)
%2 = sub i32 %_1, 1
%3 = icmp ule i32 %2, -2
call void `@llvm.assume(i1` %3)
%4 = sub i32 %_1, 1
%5 = icmp ule i32 %4, -2
call void `@llvm.assume(i1` %5)
%6 = sub i32 %_1, 1
%7 = icmp ule i32 %6, -2
call void `@llvm.assume(i1` %7)
%8 = sub i32 %_1, 1
%9 = icmp ule i32 %8, -2
call void `@llvm.assume(i1` %9)
%10 = sub i32 %_1, 1
%11 = icmp ule i32 %10, -2
call void `@llvm.assume(i1` %11)
ret i32 %_1
}
```
But those are all just newtypes that don't change size or niches, so none of it's needed.
After this PR it's down to just
```rust
define noundef range(i32 1, 0) i32 `@repeatedly_transparent_transmute(i32` noundef range(i32 1, 0) %_1) unnamed_addr {
start:
ret i32 %_1
}
```
because none of those `assume`s in the original actually did anything.
(Transmuting to something with a difference niche, though, still has the assumes -- the other tests continue to pass checking that.)
Don't include global asm in `mir_keys`, fix error body synthesis
r? oli-obk
Fixes#137470Fixes#137471Fixes#137472Fixes#137473
try-job: test-various
try-job: x86_64-apple-2
Rollup of 12 pull requests
Successful merges:
- #137337 (Add verbatim linker to AIXLinker)
- #137363 (compiler: factor Windows x86-32 ABI impl into its own file)
- #137537 (Prevent `rmake.rs` from using unstable features, and fix 3 run-make tests that currently do)
- #137606 (add a "future" edition)
- #137957 (Remove i586-pc-windows-msvc)
- #138000 (atomic: clarify that failing conditional RMW operations are not 'writes')
- #138013 (Add post-merge analysis CI workflow)
- #138033 (rustdoc: Add attribute-related tests for rustdoc JSON.)
- #138137 (setTargetTriple now accepts Triple rather than string)
- #138173 (Delay bug for negative auto trait rather than ICEing)
- #138184 (Allow anyone to relabel `CI-spurious-*`)
- #138187 (remove clones)
r? `@ghost`
`@rustbot` modify labels: rollup
Ben Kimock
The Miri Cronjob Bot
bors
Ralf Jung
Manish Goregaokar
Nicholas Nethercote
Jakub Beránek
Jacob Pratt