Move more query system code
Towards the goal of eliminating `rustc_query_system`, this commit moves some code from `rustc_query_system` to `rustc_middle` and `rustc_query_impl`, and from `rustc_middle` to `rustc_query_impl`.
r? @Zalathar
Clean up query macros for `cache_on_disk_if`
This PR aims to make the macros for dealing with `cache_on_disk_if` a bit easier to read and work with.
There should be no change to compiler behaviour.
Handle race when coloring nodes concurrently as both green and red
This fixes a race where a duplicate dep node gets written to the dep graph if a node was marked as green and promoted during execution, then marked as red after execution.
This can occur when a `no_hash` query A depends on a query B which cannot be forced so it was not colored when starting execution of query A. During the execution of query A it will execute query B and color it green. Before A finishes another thread tries to mark A green, this time succeeding as B is now green, and A gets promoted and written to metadata. Execution of A then finishes and because it's `no_hash` we assume the result changed and thus we color the node again, now as red and write it to metadata again. This doesn't happen with non-`no_hash` queries as they will be green if all their dependencies are green.
This changes the code coloring nodes red to also use `compare_exchange` to deal with this race ensuring that the coloring of nodes only happens once.
Fixesrust-lang/rust#150018Fixesrust-lang/rust#142778Fixesrust-lang/rust#141540
Rollup of 10 pull requests
Successful merges:
- rust-lang/rust#152364 (Port a lot of attributes to the new parser)
- rust-lang/rust#151954 (Add help message suggesting explicit reference cast for From/TryFrom)
- rust-lang/rust#152148 (Move `impl Interner for TyCtxt` to its own submodule)
- rust-lang/rust#152226 (Modernize diagnostic for indeterminate trait object lifetime bounds)
- rust-lang/rust#152351 (Remove `SubdiagMessage` in favour of the identical `DiagMessage`)
- rust-lang/rust#152417 (Move the needs-drop check for `arena_cache` queries out of macro code)
- rust-lang/rust#150688 (typeck: Make it clearer that `check_pat_lit` only handles literal patterns)
- rust-lang/rust#152293 (Format heterogeneous try blocks)
- rust-lang/rust#152355 (Update documentation of rustc_macros)
- rust-lang/rust#152396 (Uplift `Predicate::allow_normalization` to `rustc_type_ir`)
Format heterogeneous try blocks
The tracking issue for `try_blocks_heterogeneous` is https://github.com/rust-lang/rust/issues/149488.
This follows the formatting of homogeneous try blocks (feature `try_blocks`) by considering `try bikeshed <type>` to be the equivalent of `try` (in particular a single "token").
An alternative would be to permit breaking between `bikeshed` and `<type>`, but given that those 2 elements are an explicitly temporary part of the syntax, it doesn't seem worth it. There also doesn't seem to be any existing precedent breaking between a keyword and a type. It also doesn't seem to be useful in practice, given that the type itself doesn't break (which is how it works for the return type of closures) and has more chances to dominate the length in case a break is necessary.
Happy to adapt anything in case this formatting is not optimal.
The test is also copied from homogeneous try blocks with 2 additional test cases to demonstrate the behavior with long types.
See [#t-lang > try blocks @ 💬](https://rust-lang.zulipchat.com/#narrow/channel/213817-t-lang/topic/try.20blocks/near/572387493) for context.
typeck: Make it clearer that `check_pat_lit` only handles literal patterns
Nowadays, the `hir::PatExprKind` enum guarantees that “expressions” in patterns can only be paths or literals.
`PatExprKind::Path` is already handled by the previous match arm, so we can make this match arm explicitly match on `PatExprKind::Lit` without losing exhaustiveness.
There should be no actual change to compiler behaviour.
Move the needs-drop check for `arena_cache` queries out of macro code
This is slightly simpler than before, because now the macro only needs to call a single function, and can just unconditionally supply `tcx` and a typed arena.
There should be no actual change to compiler behaviour.
Remove `SubdiagMessage` in favour of the identical `DiagMessage`
For https://github.com/rust-lang/rust/issues/151366
Just some more cleanup :)
SubdiagMessage is now identical to DiagMessage, so there's no point in having both of them
Modernize diagnostic for indeterminate trait object lifetime bounds
* remove suggestion from the diagnostic message (bad style, too long) and turn it into a structured suggestion
* replace *object type* with *trait object type* since the former is an outdated term
Move `impl Interner for TyCtxt` to its own submodule
This impl is several hundred lines of mostly self-contained, mostly boilerplate code that can be extracted out of the dauntingly large `rustc_middle::ty::context` module.
- The trait and its impl were introduced by https://github.com/rust-lang/rust/pull/97287.
---
There should be no change to compiler behaviour.
Add help message suggesting explicit reference cast for From/TryFrom
Closesrust-lang/rust#109829
Improves E0277 diagnostics when a `From` or `TryFrom` implementation is expected, but the provided type is a reference that can be explicitly cast to a type the trait can convert from.
The latter is a new module.
As well as the code motion, some other changes were required.
- `QueryJobId` methods became free functions so they could move while
`QueryJobId` itself stayed put. This was so `QueryMap` and
`QueryJobInfo` could be moved.
- Some visibilities in `rustc_query_system` required changing.
- `collect_active_jobs_from_all_queries` is no longer required in `trait
QueryContext`.
Requiring `fn` in the macro syntax makes it a little more obvious that the
macro declares functions with those names, and makes them easier to grep for.
Remove the compiler adhoc group
Since triagebot now allows configuring rotation mode through a specific team.
Original review rotation:
```toml
compiler = [
"@BoxyUwU",
"@chenyukang",
"@davidtwco",
"@eholk",
"@fee1-dead",
"@fmease",
"@jackh726",
"@jieyouxu",
"@jdonszelmann",
"@JonathanBrouwer",
"@madsmtm",
"@mati865",
"@Nadrieril",
"@nnethercote",
"@oli-obk",
"@petrochenkov",
"@SparrowLii",
"@TaKO8Ki",
"@tiif",
"@WaffleLapkin",
"@wesleywiser",
]
```
I went through all the remaining members of t-compiler now and set their `compiler` team rotation to be off, to match the original state. You can check it with `team-stats compiler`.
r? @davidtwco
Update to Xcode 26.2
Update our CI to run with Xcode 26.
This means that:
- LLVM will be built with a newer Clang version (before Apple Clang 15, now Apple Clang 17).
- Our binaries (e.g. `rustc` and `libstd*.dylib`) will have their SDK version raised (before macOS 14.5, now 26.2).
- Our binaries will be built with a newer linker (before 1053.12, now 1230.1).
The last two points can be observed with:
```sh
$ vtool -show-build ./build/host/stage1/bin/rustc
Load command 10
cmd LC_BUILD_VERSION
cmdsize 32
platform MACOS
minos 11.0
sdk 26.2
ntools 1
tool LD
version 1230.1
$ vtool -show-build ./build/host/stage1/lib/rustlib/aarch64-apple-darwin/lib/libstd*.dylib
Load command 9
cmd LC_BUILD_VERSION
cmdsize 32
platform MACOS
minos 11.0
sdk 26.2
ntools 1
tool LD
version 1230.1
```
This shouldn't have much of an effect, but things like `dyld` is known to inspect the SDK version, so it _might_ expose some latent bugs (I really don't expect it to though).
This also updates the macOS runners to run on macOS 15 (the macOS 14 runners only have up to Xcode 16.2 available). That is desirable anyhow, as [the macOS 14 runners will be deprecated in July](https://github.com/actions/runner-images/issues/13518). This is probably also required for https://github.com/rust-lang/rust/pull/147192.
r? shepmaster
Add `s390x-unknown-none-softfloat` with `RustcAbi::Softfloat`
followup on rust-lang/rust#150766
add an `s390x-unknown-none-softfloat` target to use for kernel compilation, as the Linux kernel does not wish to pay the overhead of saving float registers by default on kernel switch. this target's `extern "C"` ABI is unspecified, so it is unstable and subject to change between versions, just like the Linux intrakernel ABI and `extern "Rust"` ABIs are unstable.
enforce target feature incompatibility by adding `RustcAbi::Softfloat`. this is itself just a rename of `RustcAbi::X86Softfloat`, accepting both "x86-softfloat" and "softfloat" as valid strings in the target.json format. the target-features of `"soft-float"` and `"vector"` are incompatible for s390x, so issue a compatibility warning if they are combined.
rustc_parse_format: improve diagnostics for unsupported debug = syntax
Detect Python-style f-string debug syntax in format strings and emit a
clear diagnostic explaining that it is not supported in Rust. When the
intended operation can be inferred, suggest the corresponding Rust
alternative (e.g. `dbg!` for `{x=}`).
Update mgca to use `type const` syntax instead of the `#[type_const]` attribute.
This PR changes the `#[type_const]` attribute to the `type const` syntax for https://github.com/rust-lang/rust/issues/132980.
This will fixes https://github.com/rust-lang/rust/issues/151273 and similar issues, since we need to check `type const` of items before expansion. The move to add a syntax was mentioned here: https://github.com/rust-lang/rust/pull/151289#issuecomment-3765241397
The first part of this PR adds support by allowing `type const <IDENT>: <TYPE> { = <EXPR> };` syntax in `rustc_parse/src/parser/item.rs`.
The next part since the AST item does not contain enough information to determine if we have a `type const` was rework `ConstItemRhs` into `ConstItemRhsKind` to store the information since we no longer have the attribute acting as a source of extra data/metadata.
The hir node `ConstItemRhsKind` current shape mostly works, except in the case of `TraitItemKind` where it is an option. I initially went about giving `hir::ConstItemRhsKind` a similar form the AST, but it touches a lot more lines of code and files so because of that, the less invasive option was to add a simple boolean flag to `TraitItemKind`.
The forth part of this PR includes adding a query I called `is_rhs_type_const` so that we can handle both local and foreign def_ids.
The fifth aspect of the PR is adding a `mgca_type_const_syntax` feature gate that is checked before expansion. The standard mgca feature gate is ran after expansion. This feature gate allows for conditional compilation (e.g #[cfg(..)]) of the `type const` syntax in nightly without `min_generic_const_args` being enabled.
The last bit is updating all the the tests that used the `#[type_const]` attribute to use the new syntax that failed because of the changes. This is the bulk of touched/edited files in the PR.
r? @BoxyUwU
@rustbot label +F-associated_const_equality +F-min_generic_const_args
Rename the query system's `JobOwner` to `ActiveJobGuard`, and include `key_hash`
`JobOwner` appears to have had more responsibilities in the past, but nowadays it's just a stack-guard object used by `execute_job` to poison the query state for the current key if some inner part of query execution panics.
The new name and comments should hopefully be clearer about its (limited) role.
I have also included a follow-up change that stores both the key and its previously-computed hash in the guard, instead of just the key. This avoids having to pass the key to `complete`, and avoids having to recompute the hash in `drop`.
r? nnethercote (or compiler)
Check stalled coroutine obligations eagerly
Fixesrust-lang/rust#151322Fixesrust-lang/rust#151323Fixesrust-lang/rust#137916Fixesrust-lang/rust#138274
The problem is that stalled coroutine obligations can't be satisifed so that they cause normalization to fail in `mir_borrowck`.
Thus, we failed to register any opaque to storage in the next solver.
I fix it by checking these obligations earlier in `mir_borrowck`.
r? @lcnr
