Reintroduce `QueryStackFrame` split.
I tried removing it in rust-lang/rust#151203, to replace it with something simpler. But a couple of fuzzing failures have come up and I don't have a clear picture on how to fix them. So I'm reverting the main part of rust-lang/rust#151203.
This commit also adds the two fuzzing tests.
Fixesrust-lang/rust#151226, rust-lang/rust#151358.
r? @oli-obk
I tried removing it in #151203, to replace it with something simpler.
But a couple of fuzzing failures have come up and I don't have a clear
picture on how to fix them. So I'm reverting the main part of #151203.
This commit also adds the two fuzzing tests.
Fixes#151226, #151358.
Revert `QueryStackFrame` split
PR rust-lang/rust#138672 fixed a query cycle OOM reported in rust-lang/rust#124901. The fix involved delaying computation of some query stack frame elements and was very complex. It involved the addition of two new types, the addition of a generic `I` parameter to eleven(!) other types, a `PhantomData` field, and even required an unsafe transmute of a closure. [This comment](https://github.com/rust-lang/rust/issues/124901#issuecomment-2104852065) had suggested a much simpler fix, but it was ignored. The PR also failed to add a test case.
This PR adds a test case, reverts the complex fix, applies the simpler fix, and does a few other minor cleanups.
r? @oli-obk
Issue #124901 was an OOM caused by a query cycle. It was fixed by
a complex change in PR #138672, but that PR did not add the test case.
Let's add it now, because it's the only known reproducer of the OOM.
Reflection MVP
I am opening this PR for discussion about the general design we should start out with, as there are various options (that are not too hard to transition between each other, so we should totally just pick one and go with it and reiterate later)
r? @scottmcm and @joshtriplett
project goal issue: https://github.com/rust-lang/rust-project-goals/issues/406
tracking issue: https://github.com/rust-lang/rust/issues/146922
The design currently implemented by this PR is
* `TypeId::info` (method, usually used as `id.info()` returns a `Type` struct
* the `Type` struct has fields that contain information about the type
* the most notable field is `kind`, which is a non-exhaustive enum over all possible type kinds and their specific information. So it has a `Tuple(Tuple)` variant, where the only field is a `Tuple` struct type that contains more information (The list of type ids that make up the tuple).
* To get nested type information (like the type of fields) you need to call `TypeId::info` again.
* There is only one language intrinsic to go from `TypeId` to `Type`, and it does all the work
An alternative design could be
* Lots of small methods (each backed by an intrinsic) on `TypeId` that return all the individual information pieces (size, align, number of fields, number of variants, ...)
* This is how C++ does it (see https://lemire.me/blog/2025/06/22/c26-will-include-compile-time-reflection-why-should-you-care/ and https://isocpp.org/files/papers/P2996R13.html#member-queries)
* Advantage: you only get the information you ask for, so it's probably cheaper if you get just one piece of information for lots of types (e.g. reimplementing size_of in terms of `TypeId::info` is likely expensive and wasteful)
* Disadvantage: lots of method calling (and `Option` return types, or "general" methods like `num_fields` returning 0 for primitives) instead of matching and field accesses
* a crates.io crate could implement `TypeId::info` in terms of this design
The backing implementation is modular enough that switching from one to the other is probably not an issue, and the alternative design could be easier for the CTFE engine's implementation, just not as nice to use for end users (without crates wrapping the logic)
One wart of this design that I'm fixing in separate branches is that `TypeId::info` will panic if used at runtime, while it should be uncallable
cleaned up cast-enum-const.rs
cleaned up ufcs-trait-object-format.rs
add comment to cast-to-box-arr.rs
add comment to shadow-primitives.rs
add comment to associated-type-const-nomalization.rs
add comment to fn-trait-explicit-call.rs
add comment to call-unit-struct-impl-fn-once.rs
add comment to cast-to-char-compare.rs
add comment to self-in-method-body-resolves.rs
add comment to derive-debug-newtype-unsized-slice.rs
add comment to tuple-ref-order-distinct-impls.rs
add comment to derive-debug-generic-with-lifetime.rs
add comment to recursive-trait-bound-on-type-param.rs
cleaned up const-static-ref-to-closure.rs
add comment to const-iter-no-conflict-for-loop.rs
Tidying up tests/ui/issues 15 tests [6/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
r? Kivooeo
add comment to closure-move-use-after-move-diagnostic.rs
add comment to missing-operator-after-float.rs
add comment to closure-array-break-length.rs
add comment to box-lifetime-argument-not-allowed.rs
add comment to const-return-outside-fn.rs
add comment to drop-conflicting-impls.rs
add comment to unbalanced-doublequote-2.rs
add comment to borrow-immutable-deref-box.rs
add comment to for-in-const-eval.rs
add comment to borrowck-annotated-static-lifetime.rs
cleaned up cast-rfc0401.rs
add comment to nll-anon-to-static.rs
add comment to cast-to-dyn-any.rs
add comment to missing-associated-items.rs
add comment to enum-discriminant-missing-variant.rs
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
Tidying up tests/ui/issues 33 tests [4/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
`tests/ui/compile-flags` split it into `tests/ui/compile-flags/invalid/` and `tests/ui/compile-flags/run-pass/`
r? Kivooeo
Fix: Prevent macro-expanded extern crates from shadowing extern arguments
prevents an ICE by fixing a logic bug in `build_reduced_graph.rs`.
the bug caused the compiler to correctly detect and report a shadowing error for a macro-expanded `extern crate` but then continue processing the invalid item, corrupting the resolver's internal state (`extern_prelude`) and leading to a crash in later resolution passes the fix adds an early return after the shadowing error is reported to ensure the invalid item is not added to the resolution graph.
Fixesrust-lang/rust#149821
Tidying up UI tests [6/N]
> [!NOTE]
> Intermediate commits are intended to help review, but will be squashed add comment commit prior to merge.
part of rust-lang/rust#133895
removed directory `tests/ui/trait-objects`, `tests/ui/for`, `tests/ui/warnings`
`trait-objects` -> `traits/object`
`for` -> `for-loop-while` (except `for/issue-20605.rs` test. this relocated to `traits/dyn-iterator-deref-in-for-loop.rs`)
`warnings` -> `resolve`, `entry-point`
r? Kivooeo
```
error[E0401]: can't use `Self` from outer item
--> $DIR/E0401.rs:22:25
|
LL | impl<T> Iterator for A<T> {
| ---- `Self` type implicitly declared here, by this `impl`
...
LL | fn helper(sel: &Self) -> u8 {
| ------ ^^^^ use of `Self` from outer item
| |
| `Self` used in this inner function
|
help: refer to the type directly here instead
|
LL - fn helper(sel: &Self) -> u8 {
LL + fn helper(sel: &A<T>) -> u8 {
|
```
Point at inner item when it uses generic type param from outer item or `Self`
Partially address rust-lang/rust#37892.
In E0401 generated in resolve:
```
error[E0401]: can't use generic parameters from outer item
--> $DIR/E0401.rs:4:39
|
LL | fn foo<T>(x: T) {
| - type parameter from outer item
LL | fn bfnr<U, V: Baz<U>, W: Fn()>(y: T) {
| ---- ^ use of generic parameter from outer item
| |
| generic parameter used in this inner function
|
help: try introducing a local generic parameter here
|
LL | fn bfnr<T, U, V: Baz<U>, W: Fn()>(y: T) {
| ++
```
In E0401 generated in hir_typeck:
```
error[E0401]: can't reference `Self` constructor from outer item
--> $DIR/do-not-ice-on-note_and_explain.rs:6:13
|
LL | impl<B> A<B> {
| ------------ the inner item doesn't inherit generics from this impl, so `Self` is invalid to reference
LL | fn d() {
LL | fn d() {
| - `Self` used in this inner item
LL | Self(1)
| ^^^^ help: replace `Self` with the actual type: `A`
```
Stuart Cook