fix(bootstrap/dist)!: change dist path for `rustc-docs` to avoid clashing
Closesrust-lang/rust#75833, part of https://github.com/rust-lang/rustup/issues/3717:
> I'd like to know if we can assign another folder name to `rustc-docs`?
> [...]
> [`@ThePuzzlemaker](https://github.com/ThePuzzlemaker)'s` `share/doc/rust/html/nightly-rustc` does look a bit weird to me (`nightly-rustc` has nothing to do with the current `rustc`, i.e. the Rustc Book, but they somehow appear similar just looking at the names).
>
> I personally would like to see something like `share/doc/rust/html/rustc-docs` or `share/doc/rust/html/rustc-api` for this component.
_https://github.com/rust-lang/rust/issues/75833#issuecomment-2002503223_
The TLDR is that currently the "rustc book"'s path clashes with "rustc APIs" (i.e. `rustc-docs`), so we change the path of the latter to make it distributable via rustup.
I'm new to `bootstrap` so please feel free to point out any inconsistencies or any extra work I'll need to do to fully land this somewhat breaking change.
Make inliner cycle detection a fallible process
The query `mir_callgraph_cyclic` is supposed to find _all_ callees that _may_ lead to a recursive call back to the given `LocalDefId`. But that query was built using a function which recurses through the call graph and tries to locally handle hitting the recursion limit during the walk. That is wrong. If the recursion limit is encountered, the set may be incomplete and thus useless. If we hit the recursion limit the only correct thing to do is bail.
Some benchmarks improve because for some functions we will bail out of the call graph walk faster. Some benchmarks regress because we do less inlining, but that is quite rare with the default recursion depth.
Originally I thought this might be a fix for https://github.com/rust-lang/rust/issues/131960, but it turns out that it is _actually_ a fix for https://github.com/rust-lang/rust/issues/146998.
Update cargo submodule
9 commits in 94c368ad2b9db0f0da5bdd8421cea13786ce4412..b54051b1505281ec7a45a250140a0ff25d33f319
2025-12-26 19:39:15 +0000 to 2025-12-30 20:35:52 +0000
- fix(log): add `dependencies` field to `UnitRegistered` (rust-lang/cargo#16448)
- Implement fine grain locking for `build-dir` (rust-lang/cargo#16155)
- feat(resolver): List features when no close match (rust-lang/cargo#16445)
- feat(report): new command `cargo report sessions` (rust-lang/cargo#16428)
- feat (patch): Display where the patch was defined in patch-related error messages (rust-lang/cargo#16407)
- test(build-rs): Reduce from 'build' to 'check' where possible (rust-lang/cargo#16444)
- feat(toml): TOML 1.1 parse support (rust-lang/cargo#16415)
- feat(report): support --manifest-path in `cargo report timings` (rust-lang/cargo#16441)
- fix(vendor): recursively filter git files in subdirectories (rust-lang/cargo#16439)
r? ghost
std: sys: fs: uefi: Ignore "." and ".." when reading directory
- At least in Unix, "." and ".." are not returned as a directory entry. So ignore these in UEFI as well.
- Will also allow using the `remove_dir_all` implementation from `sys/fs/common`.
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#150058 (Enable file locking support for Hurd)
- rust-lang/rust#150420 (Do not spill operand debuginfo to stack for AArch64 SVE predicates `<vscale x N x i1>` where `N != 16`)
- rust-lang/rust#150501 (Fix Typos in Platform Support Tables)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 2 pull requests
Successful merges:
- rust-lang/rust#150422 (mir_build: Add a `SliceLenOp` enum for use by slice-length cases/tests)
- rust-lang/rust#150509 (Adds a regression test for rust-lang/rust#137823)
r? `@ghost`
`@rustbot` modify labels: rollup
Remove the explicit branch hint from const_panic
This was asked for in PR review for equivalence with `assert!`, but we don't need likely/unlikely intrinsics here (and indeed they are a bit of an antipattern), because codegen knows about the pattern that `assert!` produces where only one target of a SwitchInt leads to a block terminated by a `#[cold]` call. All our panic entrypoints are `#[cold]`.
`assert!` does not use the likely/unlikely intrinsics, maybe it did in the past.
So the intrinsic call in `const_assert!` should be completely unnecessary. But currently it isn't, because `const_panic!` stamps out a runtime wrapper for its entrypoint which is not given `#[inline]`, citing compile times. It's not obvious to me why not using `#[inline]` would even be good in this case.
I think the runtime wrapper should have `#[inline]` or `#[cold]`, so I'm going to do 3 perf experiments here.
Just changing `const_assert!`: https://perf.rust-lang.org/compare.html?start=fabece9e9491d0a3c3655dba488881968b7c5f7a&end=f6b082cfcf880ad80b33523d5047c11654d907a8&stat=instructions:u
Also adding `#[inline]` to `const_panic!`'s runtime wrapper: https://perf.rust-lang.org/compare.html?start=fabece9e9491d0a3c3655dba488881968b7c5f7a&end=f467cc7e49b74b47da0e2cde49fc1a3140e00ff6&stat=instructions:u
Also adding `#[cold]` to `const_panic!`'s runtime wrapper: https://perf.rust-lang.org/compare.html?start=2e854a9344154564259de51385e9ec9506c0f3b7&end=fd8e098558ff08ac002b05ff78e9f91ffa6f3738&stat=instructions:u
The previous comment indicated perf would be worse with `#[inline]` on the runtime branch, but the results in this PR show that it is more mixed, and net positive. And in fact, the only regression in serde seems to be because we created a very tiny additional amount of codegen, but pushed the size of the second CGU just high enough that we no longer merge all CGUs together. So now serde (in debug with incremental disabled) has 2 CGUs instead of 1. If we just so happened to be still below the threshold where the CGUs don't merge, adding `#[inline]` would have been nearly all improvements.
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#150396 ([rustdoc] If line number setting is disabled, do not make line numbers take space)
- rust-lang/rust#150489 (Disable debuginfo when building GCC)
- rust-lang/rust#150490 (Specify bug URL when building GCC)
r? `@ghost`
`@rustbot` modify labels: rollup
alloc: specialize String::extend for slices of str
Here's a small optimization via specialization that can potentially eliminate a fair few reallocations when building strings using specific patterns, unsure if this justifies the use of unsafe, but I had the code implemented from rust-lang/rust#148604, so I thought it was worth submitting to see.
bootstrap: Use cargo's `build.warnings=deny` rather than -Dwarnings
This has two major advantages. First, it makes us less dependent on the rustc shim, which is nice but not super important. More importantly, it gives us much nicer caching properties.
Previously, `x build --warnings warn && x build --warnings deny` would rebuild all of bootstrap, and if there were any warnings emitted on the last build of the compiler, they would *not* fail the build, because cargo would cache the output rather than rerunning the shim.
After this change, bootstrap rebuilds instantly, and cargo knows that it should fail the build but *without* invalidating the cache.
<details><summary>An example of rebuilding bootstrap after a switch from warn->deny:</summary>
```
INFO: Downloading and building bootstrap before processing --help command.
See src/bootstrap/README.md for help with common commands.
Building bootstrap
Compiling bootstrap v0.0.0 (/Users/jyn/src/ferrocene3/src/bootstrap)
warning: unused variable: `x`
--> src/bootstrap/src/core/builder/mod.rs:1792:13
|
1792 | let x: ();
| ^
|
= note: `#[warn(unused_variables)]` (part of `#[warn(unused)]`) on by default
help: if this is intentional, prefix it with an underscore
|
1792 | let _x: ();
| +
help: you might have meant to pattern match on the similarly named constant `_`
|
1792 - let x: ();
1792 + let utils::render_tests::_: ();
|
warning: `bootstrap` (lib) generated 1 warning (run `cargo fix --lib -p bootstrap` to apply 1 suggestion)
Finished `dev` profile [unoptimized] target(s) in 5.14s
error: warnings are denied by `build.warnings` configuration
failed to run: /Users/jyn/src/ferrocene3/build/aarch64-apple-darwin/stage0/bin/cargo build --jobs=default --manifest-path /Users/jyn/src/ferrocene3/src/bootstrap/Cargo.toml -Zroot-dir=/Users/jyn/src/ferrocene3 -Zwarnings
```
</details>
building the compiler from scratch with `deny`: https://gist.github.com/jyn514/493ed26c2aa6f61bf47c21e75efa2175
<details><summary>and rebuilding the compiler after switching from deny->warn (note that it reuses the whole cache, there are no invalidations):</summary>
```
$ x c compiler
Building bootstrap
Finished `dev` profile [unoptimized] target(s) in 0.15s
Checking stage1 compiler artifacts{rustc-main, rustc_abi, rustc_arena, rustc_ast, rustc_ast_ir, rustc_ast_lowering, rustc_ast_passes, rustc_ast_pretty, rustc_attr_parsing, rustc_baked_icu_data, rustc_borrowck, rustc_builtin_macros, rustc_codegen_llvm, rustc_codegen_ssa, rustc_const_eval, rustc_data_structures, rustc_driver, rustc_driver_impl, rustc_error_codes, rustc_error_messages, rustc_errors, rustc_expand, rustc_feature, rustc_fluent_macro, rustc_fs_util, rustc_graphviz, rustc_hashes, rustc_hir, rustc_hir_analysis, rustc_hir_id, rustc_hir_pretty, rustc_hir_typeck, rustc_incremental, rustc_index, rustc_index_macros, rustc_infer, rustc_interface, rustc_lexer, rustc_lint, rustc_lint_defs, rustc_llvm, rustc_log, rustc_macros, rustc_metadata, rustc_middle, rustc_mir_build, rustc_mir_dataflow, rustc_mir_transform, rustc_monomorphize, rustc_next_trait_solver, rustc_parse, rustc_parse_format, rustc_passes, rustc_pattern_analysis, rustc_privacy, rustc_proc_macro, rustc_public, rustc_public_bridge, rustc_query_impl, rustc_query_system, rustc_resolve, rustc_sanitizers, rustc_serialize, rustc_session, rustc_span, rustc_symbol_mangling, rustc_target, rustc_thread_pool, rustc_trait_selection, rustc_traits, rustc_transmute, rustc_ty_utils, rustc_type_ir, rustc_type_ir_macros, rustc_windows_rc} (stage0 -> stage1, aarch64-apple-darwin)
warning: function `foo` is never used
--> compiler/rustc_hashes/src/lib.rs:16:4
|
16 | fn foo() {}
| ^^^
|
= note: `#[warn(dead_code)]` (part of `#[warn(unused)]`) on by default
warning: `rustc_hashes` (lib) generated 1 warning
Finished `release` profile [optimized + debuginfo] target(s) in 0.53s
Build completed successfully in 0:00:08
```
</details>
thanks to `@epage` for the help finding this!
r? bootstrap
Rollup of 2 pull requests
Successful merges:
- rust-lang/rust#150178 (std: Motor OS: switch to moto-rt v0.16.0)
- rust-lang/rust#150363 (xous: fix build due to function and feature name changes)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix `LinkedList::CursorMut::pop_front` to correctly update index
When `pop_front` was called while the cursor pointed to the front element, `move_next` incremented the index but it was never decremented afterwards, causing the index to incorrectly report 1 instead of 0.
Always decrement the index after popping from front using `saturating_sub` to handle edge cases safely.
Fixesrust-lang/rust#147616
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#148533 (Split LLVM intrinsic abi handling from the rest of the abi handling)
- rust-lang/rust#150358 (fix rustfmt on `const impl Ty {}`)
- rust-lang/rust#150434 (Add test for never type fallback in try blocks with `Into<!>`)
r? `@ghost`
`@rustbot` modify labels: rollup
Update cargo submodule
17 commits in e91b2baa632c0c7e84216c91ecfe107c37d887c1..94c368ad2b9db0f0da5bdd8421cea13786ce4412
2025-12-13 16:29:21 +0000 to 2025-12-26 19:39:15 +0000
- fix(vendor): unpack from local-registry cache path (rust-lang/cargo#16435)
- feat(index): Stabilize pubtime (rust-lang/cargo#16372)
- Experiment: Render timing pipeline in SVG (rust-lang/cargo#15091)
- chore(triagebot): auto-label `Command-report` (rust-lang/cargo#16429)
- fix(sbom): Don't set CARGO_SBOM_PATH when empty (like stable) (rust-lang/cargo#16419)
- chore(ci): report-timings to upload HTML report (rust-lang/cargo#16416)
- fix(report): get the same feature parity of `--timings` (rust-lang/cargo#16414)
- fix(docs): Document the only possible values for DEBUG in build scripts (rust-lang/cargo#16413)
- fix(log): emit fingeprint log also for no-rebuild unit (rust-lang/cargo#16408)
- Fix link to `doc_cfg` docs in cargo book (rust-lang/cargo#16404)
- Add best pratice for how to check in generated files (rust-lang/cargo#16405)
- test: Use a larger default term width (rust-lang/cargo#16403)
- Document more services and permissions of the cargo team (rust-lang/cargo#16402)
- fix(new): Improve quality of package name error messages (rust-lang/cargo#16398)
- feat(log): add more log events (rust-lang/cargo#16390)
- chore: bump to 0.95.0; update changelog (rust-lang/cargo#16395)
- Cache submodule into git db (rust-lang/cargo#16246)
r? ghost
Add `MaybeDangling` to `core`
This is the library part of adding `MaybeDangling`. Note that it doesn't actually do anything described in its docs (yet), I'll make a separate PR for that.
Tracking issue: https://github.com/rust-lang/rust/issues/118166.
r? libs
cc `@RalfJung`
JumpThreading: compute place and value indices on-demand
Profiling JumpThreading reveals that a large part of the runtime happens constructing the place and value `Map`. This is unfortunate, as jump-threading may end up not even doing anything.
The cause for this large up-front cost is following: `Map` attempts to create a `PlaceIndex` for each place that *may* hold a relevant value. This means all places that appear in MIR, but also all places whose value is accessed by a projection of a copy of a larger place.
This PR refactors the creation of `Map` to happen on-demand: place and value indices are created when threading computation happens.
The up-front mode is still relevant for DataflowConstProp, so is not touched.
Fix copy code example with line numbers
Fixesrust-lang/rust#150339.
Since the line numbers are now included in the actual highlighted code, we need to filter them out when we "copy" the code.
r? `@yotamofek`
Clippy subtree update
r? Manishearth
`Cargo.lock` update due to 28d62f0833. It should not affect the Rust repo, as `clippy_dev` is not used in the Rust repo.
Recursive delegation improvements
This PR fixes interaction of recently added recursive delegations with other features, such as generics inheritance and attributes inheritance. It fixesrust-lang/rust#150152 ICE, it is a part of the delegation feature rust-lang/rust#118212. This issue contains two examples with different causes of ICE:
- The cause of the [first one](https://github.com/rust-lang/rust/issues/150152#issue-3747303525) is incorrect determination of whether we are in a trait impl [here](https://github.com/rust-lang/rust/blob/c4aa646f15e40bd3e64ddb5017b7b89b3646ac99/compiler/rustc_resolve/src/late.rs#L3553), we were using `trait_id.is_some()` which in case of an unresolved trait was `None`, we should have used `of_trait` from AST level for this purpose
- The cause of the [second example](https://github.com/rust-lang/rust/issues/150152#issuecomment-3674834654) is that with recursive delegations we started to provide DefIds of the root function of the delegation for recursive delegations instead of actual delegee id. This situation is described in comments in `DelegationIds` struct, now we provide different DefIds (either immediate delegee DefId or the root function DefId in `lower_delegation` method
Moreover, this PR fixes how attributes inheritance work with recursive delegations, earlier we would have copied attributes from the root function, however now we inherit attributes from the actual delegee, for this purpose we store attributes to inherit for delegations too, in the same way they were stored for functions.
r? `@petrochenkov`
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#150141 (Misc cleanups from reading some borrowck code)
- rust-lang/rust#150297 (Fix compile issue in Vita libstd)
- rust-lang/rust#150341 (Fix some divergences with the cg_clif subtree)
r? `@ghost`
`@rustbot` modify labels: rollup
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#150311 (Avoid using env::temp when linking a binary)
- rust-lang/rust#150336 (Disable f16 on LoongArch for LLVM < 21)
- rust-lang/rust#150338 (Include rustc version in ICE messages)
r? `@ghost`
`@rustbot` modify labels: rollup
Remap both absolute and relative paths when building `rustc` and `std`
Turns out [#150110](https://github.com/rust-lang/rust/issues/150110) didn't work as expected, because when the standard library sources are present, we [helpfully un-remap the paths](https://github.com/rust-lang/rust/blob/e951f470d76febcc6f0a5b409c509eb77450a336/compiler/rustc_metadata/src/rmeta/decoder.rs#L1656-L1702) to the local directory of the user, including when we are building the compiler and standard library it-self (duh!), and since those paths are absolute (not relative), our purely relative remapping didn't pick them up.
This behavior wasn't a issue before because the un-remap logic immediately tries to remap them again, and since we had the absolute remapping we would just remap them to the the same thing.
To fix that issue I've adjusted our remapping to remap both the absolute and relative paths when building `rustc` and `std`, as well as added a run-make to make sure we don't regress it again (with a new `needs-std-remap-debuginfo` directive).
r? `@jieyouxu`
MGCA: Support struct expressions without intermediary anon consts
r? oli-obk
tracking issue: rust-lang/rust#132980Fixesrust-lang/rust#127972Fixesrust-lang/rust#137888Fixesrust-lang/rust#140275
due to delaying a bug instead of ICEing in HIR ty lowering.
### High level goal
Under `feature(min_generic_const_args)` this PR adds another kind of const argument. A struct/variant construction const arg kind. We represent the values of the fields as themselves being const arguments which allows for uses of generic parameters subject to the existing restrictions present in `min_generic_const_args`:
```rust
fn foo<const N: Option<u32>>() {}
trait Trait {
#[type_const]
const ASSOC: usize;
}
fn bar<T: Trait, const N: u32>() {
// the initializer of `_0` is a `N` which is a legal const argument
// so this is ok.
foo::<{ Some::<u32> { 0: N } }>();
// this is allowed as mgca supports uses of assoc consts in the
// type system. ie `<T as Trait>::ASSOC` is a legal const argument
foo::<{ Some::<u32> { 0: <T as Trait>::ASSOC } }>();
// this on the other hand is not allowed as `N + 1` is not a legal
// const argument
foo::<{ Some::<u32> { 0: N + 1 } }>();
}
```
This PR does not support uses of const ctors, e.g. `None`. And also does not support tuple constructors, e.g. `Some(N)`. I believe that it would not be difficult to add support for such functionality after this PR lands so have left it out deliberately.
We currently require that all generic parameters on the type being constructed be explicitly specified. I haven't really looked into why that is but it doesn't seem desirable to me as it should be legal to write `Some { ... }` in a const argument inside of a body and have that desugar to `Some::<_> { ... }`. Regardless this can definitely be a follow-up PR and I assume this is some underlying consistency with the way that elided args are handled with type paths elsewhere.
This PRs implementation of supporting struct expressions is somewhat incomplete. We don't handle `Foo { ..expr }` at all and aren't handling privacy/stability. The printing of `ConstArgKind::Struct` HIR nodes doesn't really exist either :')
I've tried to keep the implementation here somewhat deliberately incomplete as I think a number of these issues are actually quite small and self contained after this PR lands and I'm hoping it could be a good set of issues to mentor newer contributors on 🤔 I just wanted the "bare minimum" required to actually demonstrate that the previous changes are "necessary".
### `ValTree` now recurse through `ty::Const`
In order to actually represent struct/variant construction in `ty::Const` without going through an anon const we would need to introduce some new `ConstKind` variant. Let's say some hypothetical `ConstKind::ADT(Ty<'tcx>, List<Const<'tcx>>)`.
This variant would represent things the same way that `ValTree` does with the first element representing the `VariantIdx` of the enum (if its an enum), and then followed by a list of field values in definition order.
This *could* work but there are a few reasons why it's suboptimal.
First it would mean we have a second kind of `Const` that can be normalized. Right now we only have `ConstKind::Unevaluated` which possibly needs normalization. Similarly with `TyKind` we *only* have `TyKind::Alias`. If we introduced `ConstKind::ADT` it would need to be normalized to a `ConstKind::Value` eventually. This feels to me like it has the potential to cause bugs in the long run where only `ConstKind::Unevaluated` is handled by some code paths.
Secondly it would make type equality/inference be kind of... weird... It's desirable for `Some { 0: ?x } eq Some { 0: 1_u32 }` to result in `?x=1_u32`. I can't see a way for this to work with this `ConstKind::ADT` design under the current architecture for how we represent types/consts and generally do equality operations.
We would need to wholly special case these two variants in type equality and have a custom recursive walker separate from the existing architecture for doing type equality. It would also be somewhat unique in that it's a non-rigid `ty::Const` (it can be normalized more later on in type inference) while also having somewhat "structural" equality behaviour.
Lastly, it's worth noting that its not *actually* `ConstKind::ADT` that we want. It's desirable to extend this setup to also support tuples and arrays, or even references if we wind up supporting those in const generics. Therefore this isn't really `ConstKind::ADT` but a more general `ConstKind::ShallowValue` or something to that effect. It represents at least one "layer" of a types value :')
Instead of doing this implementation choice we instead change `ValTree::Branch`:
```rust
enum ValTree<'tcx> {
Leaf(ScalarInt),
// Before this PR:
Branch(Box<[ValTree<'tcx>]>),
// After this PR
Branch(Box<[Const<'tcx>]>),
}
```
The representation for so called "shallow values" is now the same as the representation for the *entire* full value. The desired inference/type equality behaviour just falls right out of this. We also don't wind up with these shallow values actually being non-rigid. And `ValTree` *already* supports references/tuples/arrays so we can handle those just fine.
I think in the future it might be worth considering inlining `ValTree` into `ty::ConstKind`. E.g:
```rust
enum ConstKind {
Scalar(Ty<'tcx>, ScalarInt),
ShallowValue(Ty<'tcx>, List<Const<'tcx>>),
Unevaluated(UnevaluatedConst<'tcx>),
...
}
```
This would imply that the usage of `ValTree`s in patterns would now be using `ty::Const` but they already kind of are anyway and I think that's probably okay in the long run. It also would mean that the set of things we *could* represent in const patterns is greater which may be desirable in the long run for supporting things such as const patterns of const generic parameters.
Regardless, this PR doesn't actually inline `ValTree` into `ty::ConstKind`, it only changes `Branch` to recurse through `Const`. This change could be split out of this PR if desired.
I'm not sure if there'll be a perf impact from this change. It's somewhat plausible as now all const pattern values that have nesting will be interning a lot more `Ty`s. We shall see :>
### Forbidding generic parameters under mgca
Under mgca we now allow all const arguments to resolve paths to generic parameters. We then *later* actually validate that the const arg should be allowed to access generic parameters if it did wind up resolving to any.
This winds up just being a lot simpler to implement than trying to make name resolution "keep track" of whether we're inside of a non-anon-const const arg and then encounter a `const { ... }` indicating we should now stop allowing resolving to generic parameters.
It's also somewhat in line with what we'll need for a `feature(generic_const_args)` where we'll want to decide whether an anon const should have any generic parameters based off syntactically whether any generic parameters were used. Though that design is entirely hypothetical at this point :)
### Followup Work
- Make HIR ty lowering check whether lowering generic parameters is supported and if not lower to an error type/const. Should make the code cleaner, fix some other bugs, and maybe(?) recover perf since we'll be accessing less queries which I think is part of the perf regression of this PR
- Make the ValTree setup less scuffed. We should find a new name for `ConstKind::Value` and the `Val` part of `ValTree` and `ty::Value` as they no longer correspond to a fully normalized structure. It may also be worth looking into inlining `ValTreeKind` into `ConstKind` or atleast into `ty::Value` or sth 🤔
- Support tuple constructors and const constructors not just struct expressions.
- Reduce code duplication between HIR ty lowering's handling of struct expressions, and HIR typeck's handling of struct expressions
- Try fix perf https://github.com/rust-lang/rust/pull/149114#issuecomment-3668038853. Maybe this will clear up once we clean up `ValTree` a bit and stop doing double interning and whatnot
Subtree sync for rustc_codegen_cranelift
The main highlight this time is a Cranelift update.
r? `@ghost`
`@rustbot` label +A-codegen +A-cranelift +T-compiler
automate offload, part 2 - clang calls
This automates steps 2+3 (the clang invocations) of the rust offload usage pipeline.
Now all that remains is a clang-linker-invocation after this step.
r? oli-obk
std: Use `usleep` temporarily on WASI targets
This fixes some fallout from rust-lang/rust#147572 where the `thread::sleep` function is is broken on `wasm32-wasip2` after that PR. The cause for this is a broken implementation of `nanosleep` in wasi-libc itself which is being fixed in WebAssembly/wasi-libc#696. Similar to rust-lang/rust#149864 this avoids the problematic function for now while the wasi-libc changes take some time to propagate into a wasi-sdk release.
Closesrust-lang/rust#150290
remove llvm_enzyme and enzyme fallbacks from most places
Using dlopen to get symbols has the nice benefit that rustc itself doesn't depend on libenzyme symbols anymore. We can therefore delete most fallback implementations in the backend (independently of whether we enable enzyme or not). When trying to use autodiff on nightly, we will now fail with a nice error if and only if we fail to load libEnzyme-21.so in our backend.
Verified:
Build as nightly, without Enzyme
Build as nightly, with Enzyme
Build as stable (without Enzyme)
With this PR we will now run `tests/ui/autodiff` on nightly, the tests are passing.
r? `@kobzol`
interpreter/visitor: always iterate in in-memory order
Now that this is directly available in the type, there's no reason to ever iterate in any other order.
Replace Rvalue::NullaryOp by a variant in mir::Operand.
Based on https://github.com/rust-lang/rust/pull/148151
This PR fully removes the MIR `Rvalue::NullaryOp`. After rust-lang/rust#148151, it was only useful for runtime checks like `ub_checks`, `contract_checks` and `overflow_checks`.
These are "runtime" checks, boolean constants that may only be `true` in codegen. It depends on a rustc flag passed to codegen, so we need to represent those flags cross-crate.
This PR replaces those runtime checks by special variants in MIR `ConstValue`. This allows code that expects constants to manipulate those as such, even if we may not always be able to evaluate them to actual scalars.
Replace Rvalue::NullaryOp by a variant in mir::Operand.
Based on https://github.com/rust-lang/rust/pull/148151
This PR fully removes the MIR `Rvalue::NullaryOp`. After rust-lang/rust#148151, it was only useful for runtime checks like `ub_checks`, `contract_checks` and `overflow_checks`.
These are "runtime" checks, boolean constants that may only be `true` in codegen. It depends on a rustc flag passed to codegen, so we need to represent those flags cross-crate.
This PR replaces those runtime checks by special variants in MIR `ConstValue`. This allows code that expects constants to manipulate those as such, even if we may not always be able to evaluate them to actual scalars.
Replace Rvalue::NullaryOp by a variant in mir::Operand.
Based on https://github.com/rust-lang/rust/pull/148151
This PR fully removes the MIR `Rvalue::NullaryOp`. After rust-lang/rust#148151, it was only useful for runtime checks like `ub_checks`, `contract_checks` and `overflow_checks`.
These are "runtime" checks, boolean constants that may only be `true` in codegen. It depends on a rustc flag passed to codegen, so we need to represent those flags cross-crate.
This PR replaces those runtime checks by special variants in MIR `ConstValue`. This allows code that expects constants to manipulate those as such, even if we may not always be able to evaluate them to actual scalars.
Better closure requirement propagation.
Fixesrust-lang/rust#148289Fixesrust-lang/rust#104477
Should unblock rust-lang/rust#148187
When propagating closure requirements we:
- no longer try to find a post dominiting region for the list of non-local lower bounds of `longer_fr`.
- we filter the list of `longer_fr-: shorter_fr+` to only these constraints between external regions which are required regardless. If no such constraint exists, we fall back to propagating all of them.
See the [FCP](https://github.com/rust-lang/rust/pull/148329#issuecomment-3581019253) for more information.
r? `@lcnr`
Update cargo submodule
13 commits in e91b2baa632c0c7e84216c91ecfe107c37d887c1..3861f60f6b58f57524c0e7aab1f5c1ad83e35409
2025-12-13 16:29:21 +0000 to 2025-12-19 21:53:33 +0000
- fix(sbom): Don't set CARGO_SBOM_PATH when empty (like stable) (rust-lang/cargo#16419)
- chore(ci): report-timings to upload HTML report (rust-lang/cargo#16416)
- fix(report): get the same feature parity of `--timings` (rust-lang/cargo#16414)
- fix(docs): Document the only possible values for DEBUG in build scripts (rust-lang/cargo#16413)
- fix(log): emit fingeprint log also for no-rebuild unit (rust-lang/cargo#16408)
- Fix link to `doc_cfg` docs in cargo book (rust-lang/cargo#16404)
- Add best pratice for how to check in generated files (rust-lang/cargo#16405)
- test: Use a larger default term width (rust-lang/cargo#16403)
- Document more services and permissions of the cargo team (rust-lang/cargo#16402)
- fix(new): Improve quality of package name error messages (rust-lang/cargo#16398)
- feat(log): add more log events (rust-lang/cargo#16390)
- chore: bump to 0.95.0; update changelog (rust-lang/cargo#16395)
- Cache submodule into git db (rust-lang/cargo#16246)
r? ghost
Perf regression fix
The only thing changed from the previous PR is that I removed `output_is_inhabited` from hot path, and hide it behind condition, so now it will compute it less frequent
follow up on https://github.com/rust-lang/rust/pull/149664
Prefer remapping the relative `library/` and `compiler/` directories
This is done to avoid leaking the relative paths to the standard library after the overall of filenames in rust-lang/rust#149709.
Noted that the paths were already leaking before, but to a lesser extent since most (but not all) the paths embedded in the distributed `rlib` were absolute.
In general Cargo compiles workspace members with relative paths, so it's better anyway to remap the relative path.
In addition to our tests I have manually confirmed that it also works as expected for the printed diagnostics paths.
cf. https://rust-lang.zulipchat.com/#narrow/channel/131828-t-compiler/topic/remapping.20of.20the.20standard.20library/near/564093571
Rollup of 3 pull requests
Successful merges:
- rust-lang/rust#147430 (cg_llvm: More preparation for moving FFI bindings to `rustc_llvm`)
- rust-lang/rust#149815 (Add regression test for rust-lang/rust#120189)
- rust-lang/rust#150127 (Port `#[rustc_lint_untracked_query_information]` and `#[rustc_lint_diagnostics]` to using attribute parsers)
r? `@ghost`
`@rustbot` modify labels: rollup
Don't treat asserts as a call in cross-crate inlining
Making functions with calls in their bodies automatically cross-crate-inlinable tends to tank incremental build times. Though assert terminators are _like_ calls, they don't exhibit the same behavior.
Make closure capturing have consistent and correct behaviour around patterns
Reference PR:
- https://github.com/rust-lang/reference/pull/1837
This PR has two goals:
- firstly, it fixesrust-lang/rust#137467. In order to do so, it needs to introduce a small breaking change surrounding the interaction of closure captures with matching against enums with uninhabited variants. Yes – to fix an ICE!
- this also fixesrust-lang/rust#138973, a slightly different case with the same root cause.
- likewise, fixesrust-lang/rust#140011.
- secondly, it fixesrust-lang/rust#137553, making the closure capturing rules consistent between `let` patterns and `match` patterns. This is new insta-stable behavior.
## Background
This change concerns how precise closure captures interact with patterns. As a little known feature, patterns that require inspecting only part of a value will only cause that part of the value to get captured:
```rust
fn main() {
let mut a = (21, 37);
// only captures a.0, writing to a.1 does not invalidate the closure
let mut f = || {
let (ref mut x, _) = a;
*x = 42;
};
a.1 = 69;
f();
}
```
I was not able to find any discussion of this behavior being introduced, or discussion of its edge-cases, but it is [documented in the Rust reference](https://doc.rust-lang.org/reference/types/closure.html#r-type.closure.capture.precision.wildcard).
The currently stable behavior is as follows:
- if any pattern contains a binding, the place it binds gets captured (implemented in current `walk_pat`)
- patterns in refutable positions (`match`, `if let`, `let ... else`, but not destructuring `let` or destructuring function parameters) get processed as follows (`maybe_read_scrutinee`):
- if matching against the pattern will at any point require inspecting a discriminant, or it includes a variable binding not followed by an ``@`-pattern,` capture *the entire scrutinee* by reference
You will note that this behavior is quite weird and it's hard to imagine a sensible rationale for at least some of its aspects. It has the following issues:
- firstly, it assumes that matching against an irrefutable pattern cannot possibly require inspecting any discriminants. With or-patterns, this isn't true, and it is the cause of the rust-lang/rust#137467 ICE.
- secondly, the presence of an ``@`-pattern` doesn't really have any semantics by itself. This is the weird behavior tracked as rust-lang/rust#137553.
- thirdly, the behavior is different between pattern-matching done through `let` and pattern-matching done through `match` – which is a superficial syntactic difference
This PR aims to address all of the above issues. The new behavior is as follows:
- like before, if a pattern contains a binding, the place it binds gets captured as required by the binding mode
- if matching against the pattern requires inspecting a disciminant, the place whose discriminant needs to be inspected gets captured by reference
"requires inspecting a discriminant" is also used here to mean "compare something with a constant" and other such decisions. For types other than ADTs, the details are not interesting and aren't changing.
## The breaking change
During closure capture analysis, matching an `enum` against a constructor is considered to require inspecting a discriminant if the `enum` has more than one variant. Notably, this is the case even if all the other variants happen to be uninhabited. This is motivated by implementation difficulties involved in querying whether types are inhabited before we're done with type inference – without moving mountains to make it happen, you hit this assert: https://github.com/rust-lang/rust/blob/43f0014ef0f242418674f49052ed39b70f73bc1c/compiler/rustc_middle/src/ty/inhabitedness/mod.rs#L121
Now, because the previous implementation did not concern itself with capturing the discriminants for irrefutable patterns at all, this is a breaking change – the following example, adapted from the testsuite, compiles on current stable, but will not compile with this PR:
```rust
#[derive(Clone, Copy, PartialEq, Eq, Debug)]
enum Void {}
pub fn main() {
let mut r = Result::<Void, (u32, u32)>::Err((0, 0));
let mut f = || {
let Err((ref mut a, _)) = r;
*a = 1;
};
let mut g = || {
//~^ ERROR: cannot borrow `r` as mutable more than once at a time
let Err((_, ref mut b)) = r;
*b = 2;
};
f();
g();
assert_eq!(r, Err((1, 2)));
}
```
## Is the breaking change necessary?
One other option would be to double down, and introduce a set of syntactic rules for determining whether a sub-pattern is in an irrefutable position, instead of querying the types and checking how many variants there are.
**This would not eliminate the breaking change,** but it would limit it to more contrived examples, such as
```rust
let ((true, Err((ref mut a, _, _))) | (false, Err((_, ref mut a, _)))) = x;
```
In this example, the `Err`s would not be considered in an irrefutable position, because they are part of an or-pattern. However, current stable would treat this just like a tuple `(bool, (T, U, _))`.
While introducing such a distinction would limit the impact, I would say that the added complexity would not be commensurate with the benefit it introduces.
## The new insta-stable behavior
If a pattern in a `match` expression or similar has parts it will never read, this part will not be captured anymore:
```rust
fn main() {
let mut a = (21, 37);
// now only captures a.0, instead of the whole a
let mut f = || {
match a {
(ref mut x, _) => *x = 42,
}
};
a.1 = 69;
f();
}
```
Note that this behavior was pretty much already present, but only accessible with this One Weird Trick™:
```rust
fn main() {
let mut a = (21, 37);
// both stable and this PR only capture a.0, because of the no-op `@-pattern`
let mut f = || {
match a {
(ref mut x @ _, _) => *x = 42,
}
};
a.1 = 69;
f();
}
```
## The second, more practically-relevant breaking change
After running crater, we have discovered that the aforementioned insta-stable behavior, where sometimes closures will now capture less, can also manifest as a breaking change. This is because it is possible that previously a closure would capture an entire struct by-move, and now it'll start capturing only part of it – some by move, and some by reference. This then causes the closure to have a more restrictive lifetime than it did previously.
See:
- https://github.com/rust-lang/rust/pull/138961#issuecomment-2761888557
- https://github.com/EC-labs/cec-assignment/pull/1
- https://github.com/tryandromeda/andromeda/pull/43
## Implementation notes
The PR has two main commits:
- "ExprUseVisitor: properly report discriminant reads" makes `walk_pat` perform all necessary capturing. This is the part that fixesrust-lang/rust#137467.
- "ExprUseVisitor: remove maybe_read_scrutinee" removes the unnecessary "capture the entire scrutinee" behavior, fixing rust-lang/rust#137553.
The new logic stops making the distinction between one particular example that used to work, and another ICE, tracked as rust-lang/rust#119786. As this requires an unstable feature, I am leaving this as future work.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#150000 (Port `#[rustc_legacy_const_generics]` to use attribute parser )
- rust-lang/rust#150060 (autodiff: emit an error if we fail to find libEnzyme)
- rust-lang/rust#150070 (Partially revert rust-lang/rust#147888 and print warning if LLVM CMake dir is missing when building Enzyme)
- rust-lang/rust#150072 (Port #[no_link] to use attribute parser)
r? `@ghost`
`@rustbot` modify labels: rollup
Fix span note for question mark expression
Fixesrust-lang/rust#144304
Seems it's better to fix the note instead of modifying the span to cover the whole expression.
r? `@estebank`
`rustc_scalable_vector(N)`
Supercedes rust-lang/rust#118917.
Initial experimental implementation of rust-lang/rfcs#3838. Introduces a `rustc_scalable_vector(N)` attribute that can be applied to types with a single `[$ty]` field (for `u{16,32,64}`, `i{16,32,64}`, `f{32,64}`, `bool`). `rustc_scalable_vector` types are lowered to scalable vectors in the codegen backend.
As with any unstable feature, there will necessarily be follow-ups as we experiment and find cases that we've not considered or still need some logic to handle, but this aims to be a decent baseline to start from.
See rust-lang/rust#145052 for request for a lang experiment.
std: small `sys` refactor
Part of rust-lang/rust#117276
The large number of files changed just results from the need to update a lot of imports. Actually this PR only:
* combines the two definitions of `RawOsError` in `sys::pal` into one in `sys::io`
* moves `FULL_BACKTRACE_DEFAULT` from `sys::pal` to `sys::backtrace`
* moves the `FromInner`/`IntoInner`/... traits into `sys` (in preparation for removing `sys_common` entirely)
Rollup of 7 pull requests
Successful merges:
- rust-lang/rust#149744 (test: update duplicate many_digits test to use f64 instead of f32)
- rust-lang/rust#149946 (mir_build: Move and rename code for partitioning match candidates)
- rust-lang/rust#149987 (Move ambient cdb discovery from compiletest to bootstrap)
- rust-lang/rust#149990 (Improve amdgpu docs: Mention device-libs and xnack)
- rust-lang/rust#149994 (Allow vector types for amdgpu)
- rust-lang/rust#149997 (Link POSIX instead of Linux manual for Instant)
- rust-lang/rust#150010 (Correct library linking for hexagon targets in run-make tests)
r? `@ghost`
`@rustbot` modify labels: rollup
bors