Rename `QueryResult` to `ActiveKeyStatus`
Long ago, this enum was also used to hold the cached result of a query evaluation that had completed successfully, so its name made some sense.
Nowadays, successful query evaluation is represented by an entry in the query's in-memory cache, which is a separate data structure.
So this enum only deals with “active” query keys, i.e. those for which query evaluation has started, but has not yet completed successfully.
---
The split between jobs and results was introduced by:
- https://github.com/rust-lang/rust/pull/50102.
---
There should be no change to compiler behaviour.
typeck_root_def_id: improve doc comment
This was initially written to be exhaustive, but one more type that can only be type-checked with its containing item has since been added, and was not mentioned. So, make it future-proof by mentioning just the one example.
Also, a previous refactor left this less readable.
This was initially written to be exhaustive, but one more type that can only be type-checked with its containing item has since been added, and was not mentioned. So, make it future-proof by mentioning just the one example.
Also, a previous refactor left this less readable.
Re-export `hashbrown::hash_table` from `rustc_data_structures`
We don't always re-export shared dependencies, but for `hashbrown::hash_table` I think it makes sense, for a few reasons:
- The lower-level `HashTable` type is already part of the public API of `rustc_data_structures` via the `ShardedHashMap` type alias, and other compiler crates currently depend on being able to access its internal hash tables.
- The `Cargo.toml` entry for `hashbrown` is non-trivial, making it harder to keep in sync and harder to move between crates as needed.
- [And we currently aren't using `[workspace.dependencies]` for various reasons.](https://github.com/rust-lang/rust/pull/146113)
- It's fine for other compiler crates to use `hash_table` specifically (with care), but they probably shouldn't be using the higher-level `hashbrown::HashMap` and `hashbrown::HashSet` types directly, because they should prefer the various map/set aliases defined by `rustc_data_structures`. Re-exporting only `hash_table` helps to discourage use of those other types.
There should be no change to compiler behaviour.
Feature-gate `mut ref` patterns in struct pattern field shorthand
Tracking issue for `mut_ref` (and other parts of Match Ergonomics 2024): https://github.com/rust-lang/rust/issues/123076https://github.com/rust-lang/rust/pull/123080 introduced `mut ref`[^1] patterns (for by-reference bindings where the binding itself is mutable), feature-gated behind the `mut_ref` feature, except for in struct pattern shorthand, where the feature gating was missing. Thus, `mut ref` patterns in struct pattern shorthand has been unintentionally stable for ~18 months (since 1.79.0 ([compiler explorer](https://rust.godbolt.org/z/4WTrvhboT))).
This PR adds feature-gating for `mut ref` patterns in struct pattern shorthand. Since this is reverting an accidental stabilization, this probably needs a crater run and a T-lang FCP?
Some alternative possibilities:
* Do nothing (let the inconsistency exist until `feature(mut_ref)` is stabilized)
* Document the existing behavior
* Do a FCW instead of fully feature-gating
* Stabilize `feature(mut_ref)`
CC https://github.com/rust-lang/rust/pull/123080#issuecomment-3746793632
CC @Nadrieril
[^1]: everything in this description also applies analogously to `mut ref mut` patterns.
GVN: Elide more intermediate transmutes
We already skipped intermediate steps like `u32` or `i32` that support any (initialized) value.
This extends that to also allow skipping intermediate steps whose values are a superset of either the source or destination type. Most importantly, that means that `usize` → `NonZeroUsize` → `ptr::Alignment` and `ptr::Alignment` → `NonZeroUsize` → `usize` can skip the middle because `NonZeroUsize` is a superset of `Alignment`.
Then `Alignment::as_usize` is updated to take advantage of that and let us remove some more locals in a few places.
r? cjgillot
Fix ICE when parsing frontmatter without newline
Fixesrust-lang/rust#151882
we can not add a normal test case for it:
- no newline at the end of file, we can bypass this with change test file name with `ignore-tidy`
- multiple errors in stderr, this conflicts with the previous bypass, seems we can not add multiple error annotations in one line
anyway, I added a `run-make` test for it.
Remove unused method `DroplessArena::contains_slice`
- This method was added for https://github.com/rust-lang/rust/pull/120128.
- It became unused in https://github.com/rust-lang/rust/pull/136593.
Checking whether a particular slice is within an arena is a bit of a sketchy operation, so if there's no pressing need for it then I think we're better off not having it lying around.
Rollup of 4 pull requests
Successful merges:
- rust-lang/rust#151262 (Introducing clap on tidy)
- rust-lang/rust#151896 (Revert enabling `outline-atomics` on various platforms)
- rust-lang/rust#151849 (refactor: remove `Ty::pinned_ref` in favor of `Ty::maybe_pinned_ref`)
- rust-lang/rust#151892 (Document enum types used as values for E0423)
Document enum types used as values for E0423
### Problem
The E0423 error explanation did not include an example for enum types being used
as values, which is a common source of confusion for users.
For example, the following code:
```rust
fn main() {
let x = Option::<i32>;
}
```
refactor: remove `Ty::pinned_ref` in favor of `Ty::maybe_pinned_ref`
Also returns the `Region` of the reference type in `Ty::maybe_pinned_Ref`.
Part of rust-lang/rust#149130.
r? jackh726
resolve: Remove `force` parameter from `resolve_ident_in_scope`
`force == true` is used for turning `Determinacy::Undetermined` into `Determinacy::Determined` during error recovery.
It's only needed in two places:
- `resolve_macro_or_delegation_path` - the normal case
- `resolve_path_with_ribs` - obscure case, only when resolving visibilities and only for improving diagnostics in `tests\ui\resolve\visibility-indeterminate.rs`, I'm not actually sure if we should keep it
In other cases `Determinacy::Undetermined` is just ignored or can be propagated.
constify `Iterator`, take IV
Like its predecessors (rust-lang/rust#92433, rust-lang/rust#102225, rust-lang/rust#106541), this PR allows one to make `Iterator` implementations `const`, and thus enables the ability to have `for` loops in `const` contexts. I've also included constifying `Option as IntoIterator`, `option::IntoIter as Iterator` as a minimal dogfooding example.
But unlike its predecessors, it uses a new attribute (not unsound anymore!) that prevents any `Iterator` extension methods from being called. This is intentionally made minimal for an initial approval, the fun stuff like `.fold`, `Range as Iterator` could be done later.
cc @rust-lang/wg-const-eval, cc @oli-obk to review the compiler parts
cc rust-lang/rust#92476
Remove redundant `IntoQueryParam` calls from query plumbing
In each of these contexts, the key must have already been converted by the caller, since otherwise it wouldn't have type `Cache::Key`.
There should be no change to compiler behaviour.
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
