Rollup of 10 pull requests
Successful merges:
- #130883 (Add environment variable query)
- #138624 (Add mipsel maintainer)
- #138672 (Avoiding calling queries when collecting active queries)
- #138935 (Update wg-prio triagebot config)
- #138946 (Un-bury chapters from the chapter list in rustc book)
- #138964 (Implement lint against using Interner and InferCtxtLike in random compiler crates)
- #138977 (Don't deaggregate InvocationParent just to reaggregate it again)
- #138980 (Collect items referenced from var_debug_info)
- #138985 (Use the correct binder scope for elided lifetimes in assoc consts)
- #138987 (Always emit `native-static-libs` note, even if it is empty)
r? `@ghost`
`@rustbot` modify labels: rollup
Use the correct binder scope for elided lifetimes in assoc consts
Beyond diagnostics this has no real effect, and it's also just about a future incompat lint. But it causes ICEs in some refactorings that I'm doing, so trying to get it out of the way
Collect items referenced from var_debug_info
The collection is limited to full debuginfo builds to match behavior of FunctionCx::compute_per_local_var_debug_info.
Fixes#138942.
Don't deaggregate InvocationParent just to reaggregate it again
Also makes it easier to add more things to it in the future (which I am doing in some local experiments, so not really a reason to do this just now, but I think this PR stands on its own).
Implement lint against using Interner and InferCtxtLike in random compiler crates
Often `Interner` defines similar methods to `TyCtxt` (but often simplified due to the simpler API surface of the type system layer for the new solver), which people will either unintentionally or intentionally import and use. Let's discourage that.
r? lcnr
Update wg-prio triagebot config
This completes the Zulip channel renaming after https://github.com/rust-lang/compiler-team/issues/848
Just nits: fixed a documentation link and the name of the Zulip channel for prioritization alerts.
r? ````@davidtwco````
Avoiding calling queries when collecting active queries
This PR changes active query collection to no longer call queries. Instead the fields needing queries have their computation delayed to when an cycle error is emitted or when printing the query backtrace in a panic.
This is done by splitting the fields in `QueryStackFrame` needing queries into a new `QueryStackFrameExtra` type. When collecting queries `QueryStackFrame` will contain a closure that can create `QueryStackFrameExtra`, which does make use of queries. Calling `lift` on a `QueryStackFrame` or `CycleError` will convert it to a variant containing `QueryStackFrameExtra` using those closures.
This also only calls queries needed to collect information on a cycle errors, instead of information on all active queries.
Calling queries when collecting active queries is a bit odd. Calling queries should not be done in the deadlock handler at all.
This avoids the out of memory scenario in https://github.com/rust-lang/rust/issues/124901.
Add environment variable query
Generally, `rustc` prefers command-line arguments, but in some cases, an environment variable really is the most sensible option. We should make sure that this works properly with the compiler's change-tracking mechanisms, such that changing the relevant environment variable causes a rebuild.
This PR is a first step forwards in doing that.
Part of the work needed to do https://github.com/rust-lang/rust/issues/118204, see https://github.com/rust-lang/rust/pull/129342 for some discussion.
r? ``@petrochenkov``
Instantiate binder before registering nested obligations for auto/built-in traits
Instead of turning a `Binder<Vec<Ty>>` into a bunch of higher-ranked predicates, instantiate the binder eagerly *once* and turn them into a bunch of non-higher-ranked predicates.
Right now this feels like a noop, but this `enter_forall_and_leak_universe` call would be the singular place where we could instantiate bound lifetime assumptions for coroutine witnesses... if we had them. Thus consolidating the binder instantiation here is useful if we want to fix the coroutine-auto-trait problem.
r? lcnr
I've intentionally used slightly vague language ("roughly"), as we don't
want to guarantee the exact invocation of `xcrun`, just hint that it's
close to that.
Update cargo
10 commits in 307cbfda3119f06600e43cd38283f4a746fe1f8b..a6c604d1b8a2f2a8ff1f3ba6092f9fda42f4b7e9
2025-03-20 20:00:39 +0000 to 2025-03-26 18:11:00 +0000
- fix(package): update tracking issue for `--message-format` (rust-lang/cargo#15354)
- docs(contrib): Expand the description of team meetings (rust-lang/cargo#15349)
- feat(package): add unstable `--message-format` flag (rust-lang/cargo#15311)
- feat(complete): Added completion for `--profile` (rust-lang/cargo#15308)
- Uplift windows Cygwin DLL import libraries (rust-lang/cargo#15193)
- do not pass cdylib link args to test (rust-lang/cargo#15317)
- fix: revert the behavior checking lockfile's VCS status (rust-lang/cargo#15341)
- Temporarily ignore cargo_test_doctest_xcompile_ignores (rust-lang/cargo#15348)
- docs: fix typo in the "Shared cache" section (rust-lang/cargo#15346)
- Fix some issues with future-incompat report generation (rust-lang/cargo#15345)
r? ghost
Use `cfg_match!` in core
All of these uses of `cfg_if!` do not utilize that `cfg_if!` works with auto-`doc(cfg)`, so no functionality is lost from switching to use `cfg_match!` instead. We *do* lose what rustfmt special support exists for `cfg_if!`, though.
Tracking issue: #115585
Remove `prev_index_to_index` field from `CurrentDepGraph`
The dep graph currently has 2 ways to map a previous index into a current index. The `prev_index_to_index` map stores the current index equivalent of a previous index. For indices which are marked green, we also store the same information in the `DepNodeColorMap`. We actually only need to known the mapping for green nodes however, so this PR removes `prev_index_to_index` and instead makes use of the `DepNodeColorMap`.
To avoid racing when promoting a node from the previous session, the encoder lock is now used to ensure only one thread encodes the promoted node. This was previously done by the lock in `prev_index_to_index`.
This also changes `nodes_newly_allocated_in_current_session` used to detect duplicate dep nodes to contain both new and previous nodes, which is simpler and can better catch duplicates.
The dep node index encoding used in `DepNodeColorMap` is tweak to avoid subtraction / addition to optimize accessing the current equivalent of a previous index.
r? `@oli-obk`
In #124902, mem-categorization got merged into ExprUseVisitor itself.
Adjust the comments that have become misleading or confusing following
this change.
A name like "report_error" suggests that the error in question might be
user facing. Use "bug" to make it clear that the error in question will
be an ICE.
