`rustc_resolve` doesn't resolve type-relative paths since that's the job
of HIR ty lowering and HIR typeck. `segment.res` comes from
`rustc_resolve` and is thus always `Res::Err`.
So just try to obtain the `TypeckResults` immediately since they contain
the actual resolution as deduced by HIR typeck.
enable more f16/f128 tests in Miri
See the individual commit messages for details.
The last commit is a drive-by comment fix that was not worth its own PR.
r? @tgross35
Add Enzyme to build-manifest and rustup
This PR adds the autodiff component (Enzyme) to build-manifest, and thus also to (nightly) Rustup.
It is marked as nightly-only and as -preview.
After this PR lands, unless I messed something up, starting with the following nightly, the following should work (on supported targets):
```bash
rustup +nightly component add enzyme
RUSTFLAGS="-Zautodiff=Enable" cargo +nightly build
```
CC @ZuseZ4
r? @Mark-Simulacrum
closes: https://github.com/rust-lang/rust/issues/145899
-Zassumptions-on-binders
r? lcnr
cc https://rust-lang.github.io/rust-project-goals/2026/assumptions_on_binders.html I would cc a tracking issue but the project goals haven't been finalized yet ^^'
Implements `-Zassumptions-on-binders`. This has a few main components:
1. We introduce a new form of region constraints for use by the trait solver which supports ORs
2. When entering binders universally inside of the trait solver we walk the bound thing and compute a list of region assumptions. We then track in the `InferCtxt` all the region outlives and type outlives mentioning a placeholder from the binder for use when handling constraints involving placeholders
3. Ideally when exiting a binder, but currently actually when computing a response inside the solver, we look through all of region constraints involving placeholders and eagerly handle these region constraints instead of returning them to the caller
This is very much a first-draft impl (though it is vaguely functional), there's a lot we need to change going forwards:
- We should really be using this new form of region constraint everywhere/more generally we shouldnt have two kinds of region constraints
- We shouldn't be computing implied bounds when entering binders, instead they should be explicit everywhere and actually checked when instantiating binders. As-is `-Zassumptions-on-binders` probably widens existing soundness holes around implied bounds due to having significantly more implied bounds
- We should be eagerly handling placeholders *everywhere* not just inside of the trait solver. Right now there will still be missing assumptions for placeholders when we do higher ranked type relations during type checking outside of the trait solver.
- I'm not normalizing our assumptions or our constraints and we should be doing both ✨
- Handling of alias outlives' involving placeholders is incomplete in a number of ways
- We should handle placeholders when leaving binders not when computing responses IMO
- Actually support OR region constraints in borrow checking and region checking ✨ right now all our OR constraints are converted into normal ANDed region constraints in root contexts.
- Right now diagnostics just point to the whole item which the unsatisfied constraints came from. this is suboptimal! fix this!
- Move universe information into InferCtxtInner so it can be rolled back by probes
- we should make some kind of test suite helper so we can directly write universal/existential quantifiers and assumptions rather than having to go through rust syntax :')
How do we actually eagerly handle constraints?
The general idea is that we have some function (`eagerly_handle_placeholders_in_universe`) which takes:
- A set of region constraints
- The universe which we want to eagerly handle constraints in
- A set of outlives assumptions associated with that universe/binder
This function will rewrite all of the region constraints which involve placeholders from the passed in universe to be in terms of variables from smaller universes (or drop the constraints if we know them to be satisfied). For example:
```rust
for<'a> where('a: 'b) {
prove ('a: 'c)
}
```
when exiting `for<'a>` we want to handle the `'!a: 'c` constraint *somehow* and we can do that by requiring that *any* of the lifetimes which `'!a` outlives, themselves outlive `'c`. In this case we can require `Or('b: 'c)` and instead of `'!a: 'c` which gives us a constraint that makes sense after exiting the forall.
some more examples:
```rust
for<'a> where('a: 'b, 'a: 'c) {
prove('a: 'd)
}
// rewritten to Or('b: 'd, 'c: 'd)
for<'a> where('b: 'a) {
prove(T: 'a)
}
// rewritten to Or(T: 'b)
```
The tricky thing here is that we want/need to avoid the trait solver knowing about *all* type outlives/region outlives assumptions. So this algorithm is implemented with only knowing about the assumptions coming from the binder that is being exited.
We want to avoid passing all outlives assumptions through the trait solver for two main reasons. The first is just perf, augmenting the `ParamEnv` with significant amounts of outlives assumptions could easily mess up caching.
The second is that it's Not Possible™️ to implement. Type checking requires trait solving inside of a closure which still has an uninferred signature, this means that there are some set of implied bounds that we just don't know about yet because we only know some inference variable is well formed and nothing else.
---
Long term we should be able to wholly rip out placeholder handling from borrow checking and we won't ever encounter placeholders outside of the binders they were produced from.
Refactor `CheckAttrVisitor` so rustfmt can format it.
I don’t have any need for this myself, but [I heard it was annoying people](https://rust-lang.zulipchat.com/#narrow/channel/147480-t-compiler.2Fdiagnostics/topic/.60.23.5Bdiagnostic.3A.3Aon_unimplemented.5D.60.20on.20trait.20methods.3F/near/594113991) and I like fixing formatting and structure problems.
The key change is that the do-nothing cases are now individual match arms instead of an enormous or-pattern. In order to achieve this cleanly, I moved the code handling `Attribute::Parsed` into a separate function matching `AttributeKind`s rather than `Attribute`s.
This also fixes `RustcAllowIncoherentImpl` being non-alphabetical because it was spelled without a leading “|” (though that by itself could be achieved by adding the optional leading “|”).
LLVM 23: Specify `returnaddress` intrinsic return type
https://github.com/llvm/llvm-project/pull/188464 made the return type of the intrinsic generic to support different pointer address spaces.
@rustbot label llvm-main
Show intrinsics::gpu in docs
It was previously not visible (unless compiling docs for amdgpu, which I guess nobody does).
Follow other specific intrinsics and always include them in docs.
Now looks like this:
<img width="1220" height="446" alt="2026-05-11_10-51-05" src="https://github.com/user-attachments/assets/c3a98f0e-2803-4697-87a8-1cc8ff01815c" />
r? @ZuseZ4 (I hope you are fine with reviewing this, please re-assign if not :))
rustdoc: Fix cosmetic issues when reporting unresolved paths in `broken_intra_doc_links`
Fix some minor issues with how the `rustdoc::broken_intra_doc_links` lint labels unresolved items:
- [`a469a4a`] For unresolved "extern prelude" links like `::unresolved::item`
- Previously: ```no item named `` in scope```
- Now: ```no item named `unresolved` in scope```
- [`eeb96fa`] Some malformed paths are now accounted for, for example:
- `std:::path`
- Previously: ```no item named `std:` in scope```
- Now: `has invalid path separator`
- `std::::path`
- Previously: ```no item named `` in scope```
- Now: `has invalid path separator`
This PR is broken down into a few commits with their own descriptions, which I hope makes reviewing easier!
Fixesrust-lang/rust#141095
[`a469a4a`]: https://github.com/rust-lang/rust/commit/a469a4ae638200c264c553e72204335e20d661a1
[`eeb96fa`]: https://github.com/rust-lang/rust/commit/eeb96fab7c7882dca4c48aa8b5817e4acbf0d7d2
Have arrays' `drop_glue` just unsize and call the slice version
It's silly to emit two loops (because of the drop ladder -- just one in panic=abort) for every array length that's dropped when we can just polymorphize to the slice version.
Built atop rust-lang/rust#154327 to avoid conflicts later, so draft for now.
r? @WaffleLapkin
jsondoclint: simplify code using idiomatic Rust
Simplify `jsondoclint` with small idiomatic Rust cleanups. No behavior changes.
- Use `matches!()` macro instead of `match` in `item_kind.rs`
- Remove unnecessary derefs and simplify Option mapping in `validator.rs`
- Replace `clone()` on Copy type with `*id`
- Fix doc comment indentation
- Remove redundant tuple parens in `tests.rs`
- Remove needless borrow and closure in `main.rs`
Verified:
- `cargo clippy -p jsondoclint --tests --quiet` → no warnings
- `cargo test -p jsondoclint --quiet` → all 5 tests pass
LLBC-linker: Do not strip debug symbols for the nvptx target anymore
With LLVM >= 20 and PTX ISA version >= 7.0 the problems described in rust-lang/rust#99248 with debug symbols seems to be fixed 🎉
Since PTX isa versions < 7.0 is unsupported on the main branch and the upcoming beta release it's possible to finally remove the hack we had where we stripped debug symbols unconditionally for the nvptx64-nvidia-cuda target.
closes: https://github.com/rust-lang/rust/issues/99248
Simplify `intrinsic::raw_eq` in MIR when possible
After https://github.com/rust-lang/rust/pull/150945 things can inline enough to have this end up specific enough that we can remove it, for example changing `raw_eq::<[u8; 4]>(a, b)` → `Transmute(a) == Transmute(b)`.
The LLVM backend can also do this (and in more cases too) but we might as well do it in MIR instead when we can so it applies to all backends and other MIR optimizations can apply afterwards.
The key change is that the do-nothing cases are now individual
match arms instead of an enormous or-pattern. In order to achieve this
cleanly, I moved the code handling `Attribute::Parsed` into a separate
function matching `AttributeKind`s rather than `Attribute`s.
This also fixes `RustcAllowIncoherentImpl` being non-alphabetical
because it was spelled without a leading “|”.
It was previously not visible (unless compiling docs for amdgpu, which
I guess nobody does).
Follow other specific intrinsics and always include them in docs.
bootstrap: Don't panic on `x install --set build.extended=true`
This was a regression from rust-lang/rust#155732.
The Cargo submodule wasn't checked out, so reading from Cargo.toml didn't work. Return a fake version during dry-runs to avoid unnecessarily checking out submodules.
Fixes https://github.com/rust-lang/rust/issues/156408.
Improve doc comments for f32::ceil() and f32::floor()
Previously ::floor() included an example showing behaviour for negative values, but ::ceil() did not. Ensure both have examples of the negative case, for both f32 and f64.
Whilst we're here, tweak the wording slightly so it reads better.
Remove some dead code for dumping MIR for a single DefId
The functions that call `dump_mir_def_ids` are themselves never called with a specific DefId; they always dump MIR for the entire crate.
remove allows_weak_linkage target spec flag
The flag doesn't actually do anything. I have no idea what it's original purpose was.
It got introduced in https://github.com/rust-lang/rust/commit/59cfe904dcfbe2c3ad5396131b3d3ba6b7179fdd, but already a few months later in https://github.com/rust-lang/rust/commit/57950982b27c6ab45509c1f2db4a01fa1d2cfebb both of its uses were removed when the entire file `src/librustc_trans/closure.rs` got deleted.
It seems like back in the day we used weak linkage for closures by default and MinGW wasn't happy about that? But not much later the way we compile closures got changed, making the work-around unnecessary. The flag has then persisted unused for 10 years. A couple of Windows/UEFI targets are setting `allows_weak_linkage: false` but I assume that was just cargo-culted.
But to be sure, let's ping the folks listed for the affected targets and other Windows folks:
@dvdhrm @nicholasbishop @Berrysoft @mati865 @thomcc @tbu- @ChrisDenton
León Orell Valerian Liehr