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
Introducing clap on tidy
### Context
Currently tidy parses paths/flags from args_os manually, and the extraction is spreading multiple files. It may be a breeding ground for bugs.
ref: https://rust-lang.zulipchat.com/#narrow/channel/326414-t-infra.2Fbootstrap/topic/How.20--ci.3Dtrue.20interact.20with.20CiEnv.3F/near/543171560
(N.B. We've talked about introducing a ci flag in tidy in that thread, but I don't do it in this PR as I don't want to put multiple changes into a PR. I will introduce the flag in a coming PR.)
### Changes
This PR replaces current parsing logic with clap. To confirm the new parser works fine, I introduce an unit test for it.
### Build time
We've concerned about how clap increases the build time. In order to confirm the increment is acceptable, I did an experiment on CI:
- Run cargo build without cache for tidy 50 times in each environment on CI
- Calculate an average and a standard deviation from the result, and plot them
Here is the graph:
<img width="943" height="530" alt="rust_tidy_build_time" src="https://github.com/user-attachments/assets/c7deee69-9f38-4044-87dc-76d6e7384f76" />
- Clap tends to increase build time ~2s. We think this is not a big problem
- Build time differs in each environment
- In some cases standard deviation are high, I suppose that busyness of CI instances affect build time
Remove duplicated code in `slice/index.rs`
Looks like `const fn` is far enough along now that we can just not have these two copies any more, and have one call the other.
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.
