Rollup of 5 pull requests
Successful merges:
- rust-lang/rust#153769 (target specs: stricter checks for LLVM ABI values, and correlate that with cfg(target_abi))
- rust-lang/rust#153811 (Don't pass a separate `DepKind` to `query_feed`)
- rust-lang/rust#153817 (relocate several ui tests)
- rust-lang/rust#153840 (tests/debuginfo/basic-stepping.rs: Add cdb test)
- rust-lang/rust#153858 (Use named fields in ChunkedBitSet's `Chunk::Mixed`)
Use named fields in ChunkedBitSet's `Chunk::Mixed`
This helps to clarify that the field with type `ChunkSize` is a count of 1s, not a length or size.
There should be no change to compiler behaviour.
Don't pass a separate `DepKind` to `query_feed`
This PR makes two small tweaks to the `query_feed` function, which is called by macro-generated methods on TyCtxtFeed:
- Don't pass `DepKind` as a separate argument, because it's already in the QueryVTable
- Rename `query_vtable` to `query`, to match other functions that take QueryVTable
r? nnethercote (or compiler)
target specs: stricter checks for LLVM ABI values, and correlate that with cfg(target_abi)
This tightens the checks for `llvm_abiname`, `llvm_floatabi` and `rustc_abi` in our target specs. Those are the fields that actually control the ccABI. With this commit, we now have an allowlist of value for these fields for all architectures (we previously only had that for some architectures). We also check that `cfg(target_abi)` suitably correlates with the actual ccABI. I based this check on our in-tree targets. For all ccABIs where we had a bunch of "random" values that don't directly correlate to the ccABI (like "uwp"), I also allowed `cfg(target_abi)` to remain empty, and whenever it is allowed to be empty I also allowed arbitrary other values for JSON targets. However, there's still a risk that JSON targets will fail this new check -- the idea is that we'll then get bugreports and can adjust the check as needed.
I had to adjust the target specs for non-ARM32 Apple targets as those were all setting `llvm_floatabi`, which to my knowledge makes no sense -- LLVM only actually does anything with that field on ARM32. I also adjusted the target specs for MIPS32 targets: one of them was setting llvm_abiname, and then it seems safer and more consistent to set that for all targets, so I set it to "o32" everywhere which seems to be the default.
Cc @workingjubilee
Remove `value_from_cycle_error` specializations
This removes `value_from_cycle_error` specializations which are not involved in custom cycle error handling.
This is a step towards removing query cycle recovery.
Reimplement const closures
Tracking issue: rust-lang/rust#106003
Best reviewed commit-by-commit
The old solver can't handle `for<'a> |x: &'a()| ()` closures in const contexts, but that feature is unstable itself, so we can just leave it to the next solver to handle.
We need a lot more tests, we're testing the bare minimum of success and failure paths right now.
r? @fee1-dead
Move and expand the big `rustc_query_impl` macro into a physical `query_impl.rs`
While looking through https://github.com/rust-lang/rust/pull/153588, I came up with a related but different change that I think resolves a lot of tension in the current module arrangement.
The core idea is that if we both define and expand the big macro in the same physical module `rustc_query_impl::query_impl`, then we no longer need to worry about where `mod query_impl` should be declared, or where its imports should go, because those questions now have simple and obvious answers.
The second commit follows up with some more changes inspired by https://github.com/rust-lang/rust/pull/153588. Those particular follow-ups are not essential to the main idea of this PR.
r? nnethercote
Replace `visit_waiters` with `abstracted_waiters_of`
This replaces `visit_waiters` which uses closures to visit waiters with `abstracted_waiters_of` which returns a list of waiters. This makes the control flow of their users a bit clearer.
Additionally `abstracted_waiters_of` includes non-query waiters unlike `visit_waiters`. This means that `connected_to_root` now considers resumable waiters from the compiler root as being connected to root, while previously only non-resumable waiters counted. This can result in some additional entry points being found. Similarly in the loop detecting entry points we now consider queries in the cycle with direct resumable waiters from the compiler root as being entry points.
When looking for entry points we now look at waiters until we found a query to populate the `EntryPoint.waiter` field instead of stopping when we determined it to be an entry point.
cc @petrochenkov @nnethercote
LinkedGraph: support adding nodes and edges in arbitrary order
If an edge uses some not-yet-known node, we just leave the node's data empty, that data can be added later.
Use this support to avoid skipping edges in RetainedDepGraph.
This is continuation of https://github.com/rust-lang/rust/pull/152590, that PR just fixes the ICE, this PR also preserves all the edges in debug dumps.
This is also a minimized version of https://github.com/rust-lang/rust/pull/151821 with a smaller amount of data structure hacks.
The query's dep kind can be obtained from its vtable instead.
This commit also renames the `query_vtable` parameter to `query`, to be more
consistent with other functions that take a QueryVTable.
Moving the macro and its expansion into the same physical file resolves a lot
of tension in the current module arrangement.
Code in the macro is now free to use plain imports in the same file, and there
is no longer any question of whether `mod query_impl` should be declared inside
the macro, or surrounding a separate expansion site.
Rename `opt_span_diag_lint` into `opt_span_lint` and remove `emit_diag_lint`
Part of https://github.com/rust-lang/rust/issues/153099.
Should be the last naming cleanup hopefully. :)
r? @JonathanBrouwer
Remove `CycleErrorHandling`.
This PR removes the `cycle_*` query modifiers and `CycleErrorHandling`. Some good simplicity wins. Details in individual commits.
r? @Zalathar
Currently if a cycle error occurs the error is created, then handled
according to `CycleErrorHandling` (which comes from the
`cycle_delay_bug` query modifer, or lack thereof), and then
`value_from_cycle_error` is called.
This commit changes things so the error is created and then just passed
to `value_from_cycle_error`. This gives `value_from_cycle_error` full
control over how it's handled, eliminating the need for
`CycleErrorHandling`. This makes things simpler overall.
`collect_active_jobs_from_all_queries` takes a `require_complete` bool,
and then some callers `expect` a full map result while others allow a
partial map result. The end result is four possible combinations, but
only three of them are used/make sense.
This commit introduces `CollectActiveJobsKind`, a three-value enum that
describes the three sensible combinations, and rewrites
`collect_active_jobs_from_all_queries` around it. This makes it and its
call sites much clearer, and removes the weird `Option<()>` and
`Result<QueryJobMap, QueryJobMap>` return types.
Other changes of note.
- `active` is removed. The comment about `make_frame` is out of date,
and `create_deferred_query_stack_frame` *is* safe to call with the
query state locked.
- When shard locking failure is allowed, collection no longer stops on
the first failed shard.
Update the minimum external LLVM to 21
With this change, we'll have stable support for LLVM 21 and 22.
For reference, the previous increase to LLVM 20 was rust-lang/rust#145071.
cc @rust-lang/wg-llvm
r? nikic
Add a `TaggedQueryKey` to identify a query instance
This adds back a `TaggedQueryKey` enum which represents a query kind and the associated key. This is used to replace `QueryStackDeferred` and `QueryStackFrameExtra` and the associated lifting operation for cycle errors
This approach has a couple of benefits:
- We only run description queries when printing the query stack trace in the panic handler
- The unsafe code for `QueryStackDeferred` is removed
- Cycle handles have access to query keys, which may be handy
Some further work could be replacing `QueryStackFrame` with `TaggedQueryKey` as the extra information can be derived from it.
`execute_job` has a single call site in `try_execute_query`. This commit
inlines and removes `execute_job`, but also puts the part that checks
feedable results in its own separate function, `check_feedable`, because
it's a nicely separate piece of logic.
The big win here is that all the code dealing with the `QueryState` is
now together in `try_execute_query`: get the lock, do the lookup, drop
the lock, create the job guard, and complete the job guard. Previously
these steps were split across two functions which I found hard to
follow.
This commit purely moves code around, there are no other changes.
Rename `rustc_middle::lint::diag_lint_level` into `lint_level`
Part of https://github.com/rust-lang/rust/issues/153099.
Renaming back `diag_lint_level` into `lint_level` since the original function was completely replaced and removed.
r? @JonathanBrouwer
bors