Run regression test for #147964 on next solver too
Original regression: rust-lang/rust#147964
Longer-term tracking of issue: rust-lang/rust#148028
For now, this just makes sure that whatever tests we keep are working the same under both the current solver and the next solver, until we decide what to do with them.
Move rustdoc tests to appropriate subdirectories
## Summary
This PR reorganizes rustdoc tests into their correct subdirectories for better categorization and maintainability.
## Changes
- Moved 6 lint-related tests to `tests/rustdoc-ui/lints/`
- Moved 2 intra-doc link tests to `tests/rustdoc-ui/intra-doc/`
- Moved 3 deref-related tests to `tests/rustdoc-ui/deref/`
- Moved 1 doc-cfg test to `tests/rustdoc/doc-cfg/`
## Tests
All moved tests have been verified and pass in their new locations.
Skip parameter attribute deduction for MIR with `spread_arg`
When a MIR argument is spread at ABI level, deduced attributes are potentially misapplied, since a spread argument can correspond to zero or more arguments at ABI level.
Disable deduction for MIR using spread argument for the time being.
Contract variable declarations
This change adds contract variables that can be declared in the `requires` clause and can be referenced both in `requires` and `ensures`, subject to usual borrow checking rules. This allows any setup common to both the `requires` and `ensures` clauses to only be done once.
In particular, one future use case would be for [Fulminate](https://dl.acm.org/doi/10.1145/3704879)-like ownership assertions in contracts, that are essentially side-effects, and executing them twice would alter the semantics of the contract.
As of this change, `requires` can now be an arbitrary sequence of statements, with the final expression being of type `bool`. They are executed in sequence as expected, before checking if the final `bool` expression holds.
This PR depends on rust-lang/rust#144438 (which has now been merged).
Contracts tracking issue: https://github.com/rust-lang/rust/issues/128044
**Other changes introduced**:
- Contract macros now wrap the content in braces to produce blocks, meaning there's no need to wrap the content in `{}` when using multiple statements. The change is backwards compatible, in that wrapping the content in `{}` still works as before. The macros also now treat `requires` and `ensures` uniformally, meaning the `requires` closure is built inside the parser, as opposed to in the macro.
**Known limiatations**:
- Contracts with variable declarations are subject to the regular borrow checking rules, and the way contracts are currently lowered limits the usefulness of contract variable declarations. Consider the below example:
```rust
#[requires(let init_x = *x; true)]
#[ensures(move |_| *x == 2 * init_x)]
fn double_in_place(x: &mut i32) {
*x *= 2;
}
```
We have used the new variable declarations feature to remember the initial value pointed to by `x`, however, moving `x` into the `ensures` does not pass the borrow checker, meaning the above function contract is illegal. Ideally, something like the above should be expressable in contracts.
Accept trivial consts based on trivial consts
This is an expansion of https://github.com/rust-lang/rust/pull/148040.
The previous implementation only accepted trivial consts that assign a literal. For example:
```rust
const A: usize = 0;
const B: usize = A;
```
Before this PR, only `A` was a trivial const. Now `B` is too.
When a MIR argument is spread at ABI level, deduced attributes are
potentially misapplied, since a spread argument can correspond to zero
or more arguments at ABI level.
Disable deduction for MIR using spread argument for the time being.
rustdoc: remove `--emit=unversioned-shared-resources`
This option hasn't done anything for a long time, and can be removed. I've kept a shim in place to avoid breaking docs.rs, but the option no longer does anything.
Using git-blame, I tracked this option down to
f77ebd4ffa, the commit that introduced EmitType in the first place. It was used with SharedResource::Unversioned, which no longer exists since f9e1f6ffdf removed them.
CC https://github.com/rust-lang/rust/pull/146220
Part of https://github.com/rust-lang/rust/issues/83784
Emit delayed bug during wfck for stranded opaque
Fixes https://github.com/rust-lang/trait-system-refactor-initiative/issues/235
## Problem
The fundamental issue here is ``OpaqueTypeCollector`` operates on ``rustc_middle::Ty``, but ``check_type_wf`` operates on HIR.
Since [check_type_wf](2f7620a5cc/compiler/rustc_hir_analysis/src/check/wfcheck.rs (L2262)) operates on HIR, it can see the stranded opaque and tries to infer it's hidden type. But ``OpaqueTypeCollector`` operates on ``rustc_middle::Ty``, so the ``OpaqueTypeCollector`` can no longer see a stranded opaque, hence its hidden type could not be inferred.
As a result, the tests ICE'ed at 34a8c7368c/compiler/rustc_hir_analysis/src/collect/type_of/opaque.rs (L253)
## Proposed solution
This PR detects stranded opaque types during wf check and emit a delayed bug for it.
## Alternative solution
`@BoxyUwU` and I had considered rewriting ``OpaqueTypeCollector`` to be a HIR visitor instead of a ``rustc_middle::Ty`` visitor, but we believe a HIR-based ``OpaqueTypeCollector`` will not work and might not worth the cost of rewriting.
## Acknowledgement
This PR is a joint effort with `@BoxyUwU` :3
CFI: Fix types that implement Fn, FnMut, or FnOnce
When looking for instances which could either be dynamically called through a vtable or through a concrete trait method, we missed `FnPtrShim`, instead only looking at `Item` and closure-likes. Fixesrust-lang/rust#144641.
cc ```@1c3t3a``` ```@Jakob-Koschel```
Do not lifetime-extend array/slice indices
When lowering non-overloaded indexing operations to MIR, this uses the temporary lifetime of the index expression for the index temporary, rather than applying the temporary lifetime of the indexing operation as a whole to the index.
For example, in
```rust
let x = &xs[i];
```
previously, the temporary containing the result of evaluating `i` would live until the end of the block due to the indexing operation being [lifetime-extended](https://doc.rust-lang.org/nightly/reference/destructors.html#temporary-lifetime-extension). Under this PR, the index temporary only lives to the end of the `let` statement because it uses the more precise temporary lifetime of the index expression.
I don't think this will affect semantics in an observable way, but the more precise `StorageDead` placement may slightly improve analysis/codegen performance.
r? mir
This option hasn't done anything for a long time, and can be
removed. I've kept a shim in place to avoid breaking docs.rs,
but the option no longer does anything.
Using git-blame, I tracked this option down to
f77ebd4ffa, the commit that
introduced EmitType in the first place. It was used with
SharedResource::Unversioned, which no longer exists since
f9e1f6ffdf removed them.
CC https://github.com/rust-lang/rust/pull/146220
Part of https://github.com/rust-lang/rust/issues/83784
When looking for instances which could either be dynamically called
through a vtable or through a concrete trait method, we missed
`FnPtrShim`, instead only looking at `Item` and closure-likes.
Add a fast path for lowering trivial consts
The objective of this PR is to improve compilation performance for crates that define a lot of trivial consts. This is a flamegraph of a build of a library crate that is just 100,000 trivial consts, taken from a nightly compiler:
<img width="842" height="280" alt="2025-10-25-164005_842x280_scrot" src="https://github.com/user-attachments/assets/e5400aaf-03bd-4461-b905-054aa82ca60f" />
My objective is to target all of the cycles in `eval_to_const_value_raw` that are not part of `mir_built`, because if you look at the `mir_built` for a trivial const, we already have the value available.
In this PR, the definition of a trivial const is this:
```rust
const A: usize = 0;
```
Specifically, we look for if the `mir_built` body is a single basic block containing one assign statement and a return terminator, where the assign statement assigns an `Operand::Constant(Const::Val)`. The MIR dumps for these look like:
```
const A: usize = {
let mut _0: usize;
bb0: {
_0 = const 0_usize;
return;
}
}
```
The implementation is built around a new query, `trivial_const(LocalDefId) -> Option<(ConstValue, Ty)>` which returns the contents of the `Const::Val` in the `mir_built` if the `LocalDefId` is a trivial const.
Then I added _debug_ assertions to the beginning of `mir_for_ctfe` and `mir_promoted` to prevent trying to get the body of a trivial const, because that would defeat the optimization here. But these are deliberately _debug_ assertions because the consequence of failing the assertion is that compilation is slow, not corrupt. If we made these hard assertions, I'm sure there are obscure scenarios people will run into where the compiler would ICE instead of continuing on compilation, just a bit slower. I'd like to know about those, but I do not think serving up an ICE is worth it.
With the assertions in place, I just added logic around all the places they were hit, to skip over trying to analyze the bodies of trivial consts.
In the future, I'd like to see this work extended by:
* Pushing detection of trivial consts before MIR building
* Including DefKind::Static and DefKind::InlineConst
* Including consts like `_1 = const 0_usize; _0 = &_1`, which would make a lot of promoteds into trivial consts
* Handling less-trivial consts like `const A: usize = B`, which have `Operand::Constant(Const::Unevaluated)`
Mark desugared range expression spans with DesugaringKind::RangeExpr
This is a prerequisite to removing `QPath::LangItem` (rust-lang/rust#115178) because otherwise there would be no way to detect a range expression in the HIR.
There are some non-obvious Clippy changes so a Clippy team review would be good.
Reorganize rustdoc tests into their correct subdirectories for better
categorization:
- Move lint-related tests to rustdoc-ui/lints/
- Move intra-doc link tests to rustdoc-ui/intra-doc/
- Move deref-related tests to rustdoc-ui/deref/
- Move doc-cfg test to rustdoc/doc-cfg/
This improves test organization and makes it easier to find tests
related to specific rustdoc functionality.
Deduce captures(none) for a return place and parameters
Extend attribute deduction to determine whether parameters using
indirect pass mode might have their address captured. Similarly to
the deduction of `readonly` attribute this information facilitates
memcpy optimizations.
Extend attribute deduction to determine whether parameters using
indirect pass mode might have their address captured. Similarly to
the deduction of `readonly` attribute this information facilitates
memcpy optimizations.
StateTransform: Only load pin field once.
The current implementation starts by transforming all instances of `_1` into `(*_1)`, and then traverses the body again to transform `(*_1)` into `(*(_1.0))`, and again for `Derefer`.
This PR changes the implementation to only traverse the body once. As `_1.0` cannot be not modified inside the body (we just changed its type!), we have no risk of loading from the wrong pointer.
chore: Update to the latest annotate-snippets
This PR updates `annotate-snippets` to the latest version and updates the adapter code[^1] so that `AnnotateSnippetEmitter`'s output matches `HumanEmitter`'s output. If anyone would like to see the differences[^2] between `AnnotateSnippetEmitter` and `HumanEmitter`, [I have a branch](https://github.com/Muscraft/rust/tree/annotate-snippets-default-renderer) where `AnnotateSnippetEmitter` is used in place of `HumanEmitter`.
[^1]: A lot of the adapter code changes are based on code for `HumanEmitter`.
[^2]: Some of the test differences will go away when rust-lang/rust#148001 and rust-lang/rust#148004 are merged.
Improvements to attribute suggestions
Changes in commit 1:
- Add `AcceptContext::suggestions`, which retrieves the suggestions for the currently parsing attribute
- This happens to fix a bug in the way `#[macro_export`]. Closes https://github.com/rust-lang/rust/pull/147987
Changes in commit 2:
- Add a check to the suggestions function so the suggestions for attributes in cfg_attr are nicer. Fixes https://github.com/rust-lang/rust/issues/147693
This is also part (but not all) of the changes needed to unblock https://github.com/rust-lang/rust/pull/147945
r? `@jdonszelmann`
Stop passing resolver disambiguator state to AST lowering.
AST->HIR lowering can use a disjoint set of `DefPathData` as the resolver, so we don't need to pass the disambiguator state.
r? `@oli-obk`
test(frontmatter): Rename tests to make coverage more obvious
When working on the stabilization report (rust-lang/rust#148051), I found it annoying to determine what cases were covered because areas of the frontmatter feature were either not in the file name or in inconsistent locations.
This moves the area of frontmatter to the start of the file name and the moves to more specific the later in the file name so coverage is easier to see.
Tracking issue: rust-lang/rust#136889
Remove needs-asm-support directive in tests with explicit targets
The `needs-asm-support` directive checks whether the host architecture supports inline assembly, not the target architecture. For tests that explicitly specify a target via `--target` in their compile-flags, this directive is incorrect and unnecessary.
These tests are cross-compiling to specific targets (like x86_64, arm, aarch64, riscv, etc.) that are already known to have stable asm support. The directive was causing these tests to be incorrectly skipped on hosts that don't support asm, even though the target does.
Tests with explicit targets should rely on `needs-llvm-components` to ensure the appropriate backend is available, rather than checking host asm support.
