Make some load-from-disk function pointers optional in query vtables
For queries that never incremental-cache to disk, we can represent that fact with None (i.e. a null function pointer) in their vtables, and avoid having to generate stub functions that do nothing.
(There is no decrease in vtable size; we just go from 3/8 padding bytes to 4/8 padding bytes.)
There should be no change to compiler output.
Fix missing syntax context in lifetime hygiene debug output
`-Zunpretty=expanded,hygiene` was not printing the syntax context for lifetimes. For example, two macro-generated lifetimes `'a` with different hygiene would both print as `/* 2538 */` instead of `/* 2538#0 */` and `/* 2538#1 */`, making it impossible to distinguish them.
This was fixed by changing `print_lifetime` to call `ann_post()` with the full `Ident`, matching how regular identifiers are handled in `print_ident`.
Closes: rust-lang/rust#151797
Document a safety condition for `TypedArena::alloc_raw_slice`
This method was marked safe in https://github.com/rust-lang/rust/pull/116224/commits/51edc219906f0973dd66b4b6ff5ff0ac857a4cc6, because there was no apparent reason for it to be unsafe.
However, I believe that `alloc_raw_slice` does actually impose a significant safety obligation on its caller, because the caller must ensure that each slot in the slice is properly initialized before the arena is dropped.
This is because the arena's Drop impl will unconditionally drop every storage slot that has been handed out, so it has no way to handle slots that were accidentally left uninitialized because a hypothetical caller of `alloc_raw_slice` panicked before initializing them.
Reduce generics use in the query system.
In rust-lang/rust#151203 I tried and failed to simplify `QueryStackFrame`. This is an alternative approach. There is no functional change, just tweaking of some names and types to make things clearer. Best reviewed one commit at a time.
r? @oli-obk
privacy: Fix privacy lints in RPITITs
Visit RPITITs and report `private_interfaces`, `private_bounds` and `exported_private_dependencies` in them (these are regular, non-deprecation lints).
New hard errors are not reported, https://github.com/rust-lang/rust/pull/146470 is for hard errors.
So this PR doesn't contain any breakage or language changes.
`QueryStackFrame<I>` is a generic type, and the `I` parameter leaks out
to many other related types. However, it only has two instantiations in
practice:
- `QueryStackFrame<QueryStackFrameExtra>`
- `QueryStackFrame<QueryStackDeferred<'tcx>>`
And most of the places that currently use `QueryStackFrame<I>` are
actually specific to one of the instantiations. This commit removes the
unneeded genericity.
The following types are only ever used with `QueryStackDeferred<'tcx>`:
- QueryMap
- QueryJobInfo
- QueryJob
- QueryWaiter
- QueryLatchInfo
- QueryLatch
- QueryState
- QueryResult
and their `<I>` parameter is changed to `<'tcx>`.
Also, the `QueryContext::QueryInfo` associated type is removed.
`CycleError<I>` and `QueryInfo<I>` are still generic over type, because
they are used with both instantiations.
This required also adding a `<'tcx>` parameter to the traits
`QueryDispatcher` and `QueryContext`, which is annoying but I can't see
how to avoid it.
Fix accidental type inference in array coercion
Fixesrust-lang/rust#136420.
If the expectation of array element is a type variable, we should avoid resolving it to the first element's type and wait until LUB coercion is completed.
We create a free type variable instead which is only used in this `CoerceMany`.
[`check_expr_match`](847e3ee6b0/compiler/rustc_hir_typeck/src/_match.rs (L72)) and [`check_expr_if`](847e3ee6b0/compiler/rustc_hir_typeck/src/expr.rs (L1329)) where `CoerceMany` is also used do the [same](847e3ee6b0/compiler/rustc_hir_typeck/src/expectation.rs (L50)).
### [FCP Proposal](https://github.com/rust-lang/rust/pull/140283#issuecomment-2933771068):
> Array expressions normally lub their element expressions' types to ensure that things like `[5, 5_u8]` work and don't result in type mismatches. When invoking a generic function `fn foo<T>(_: [T; N])` with an array expression, we end up with an infer var for the element type of the array in the signature. So when typecking the first array element we compare its type with the infer var and thus subsequently require all other elements to be the same type.
>
> This PR changes that to instead fall back to "not knowing" that the argument type is array of infer var, but just having an infer var for the entire argument. Thus we typeck the array expression normally, lubbing the element expressions, and then in the end comparing the array expression's type with the array of infer var type.
>
> Things like
>
> ```rust
> fn foo() {}
> fn bar() {}
> fn f<T>(_: [T; 2]) {}
>
> f([foo, bar]);
> ```
>
> and
>
> ```rust
> struct Foo;
> struct Bar;
> trait Trait {}
> impl Trait for Foo {}
> impl Trait for Bar {}
> fn f<T>(_: [T; 2]) {}
>
> f([&Foo, &Bar as &dyn Trait]);
> ```
### Remaining inconsistency with `if` and `match`(rust-lang/rust#145048):
The typeck of array always uses the element coercion target type as the expectation of element exprs while `if` and `match` use `NoExpectation` if the expected type is an infer var.
This causes that array doesn't support nested coercion.
```rust
fn foo() {}
fn bar() {}
fn main() {
let _ = [foo, if false { bar } else { foo }]; // type mismatch when trying to coerce `bar` into `foo` in if-then branch coercion.
}
```
But we can't simply change this behavior to be the same as `if` and `match` since [many code](https://github.com/rust-lang/rust/pull/140283#issuecomment-3190564399) depends on using the first element's type as expectation.
Use `Rustc` prefix for `rustc` attrs in `AttributeKind`
cc rust-lang/rust#131229
Most `rustc_...` attrs have their variants named `RustcAttrName`, but several do not. Rename these attributes for consistency.
r? @jdonszelmann
thread::scope: document how join interacts with TLS destructors
Fixes https://github.com/rust-lang/rust/issues/116237 by documenting the current behavior regarding thread-local destructors as intended. (I'm not stoked about this, but documenting it is better than leaving it unclear.)
This also adds documentation for explicit `join` calls (both for scoped and regular threads), saying that those *will* wait for TLS destructors. That reflects my understanding of the current implementation, which calls `join` on the native thread handle. Are we okay with guaranteeing that? I think we should, so people have at least some chance of implementing "wait for all destructors" manually. This fixes https://github.com/rust-lang/rust/issues/127571.
Cc @rust-lang/libs-api
Rename, clarify, and document code for "erasing" query values
In order to reduce compile times and code size for the compiler itself, the query system has a mechanism for “erasing” and ”restoring” query values in certain contexts. See https://github.com/rust-lang/rust/pull/109333 for the original implementation.
Unfortunately, the erasure system has very little documentation, and involves a dizzying assortment of similarly-named types, traits, and functions.
This PR therefore renames several parts of the erasure API and implementation to hopefully be clearer, and adds comments to better explain the purpose and mechanism behind value erasure.
Summary of renames:
- fn `erase` → `erase_val` (avoiding ambiguity with module `erase`)
- fn `restore` → `restore_val`
- type `Erase<T>` → `Erased<T>` (for actual erased values of `T`)
- trait `EraseType` → `Erasable` (for types that can be erased and restored)
- associated type `EraseType::Result` → `Erasable::Storage`
- implementation-detail struct `Erased<T>` → `ErasedData<Storage>`
There should be no change to compiler behaviour.
Suggest ignore returning value inside macro for unused_must_use lint
Fixesrust-lang/rust#151269
The first commit fix the original issue,
the second commit is a code refactoring in this lint.
