Extract `DepKindVTable` constructors to their own module by Zalathar · Pull Request #152515 · rust-lang/rust

Zalathar · 2026-02-12T04:33:12Z

This is a fairly substantial chunk of code in rustc_query_impl::plumbing that mostly doesn't need to be inside a macro at all.

The part that does need to be in a macro is the declaration of a named vtable constructor function for each query. I have extracted that into its own separate call to rustc_middle::rustc_with_all_queries! in the new module, so that dep-kind vtable construction is almost entirely confined to rustc_query_impl::dep_kind_vtables.

There should be no change to compiler behaviour.

r? nnethercote (or compiler)

Zalathar · 2026-02-12T04:35:10Z

compiler/rustc_query_impl/src/plumbing.rs

+#[expect(unused_imports, reason = "used by doc comments")]
+use rustc_middle::dep_graph::DepKindVTable;


At first I tried using #[cfg(doc)] here, but that seems to break the ability to follow the link by command-clicking, at least in rust-analyzer.

Zalathar · 2026-02-12T04:36:51Z

compiler/rustc_query_impl/src/plumbing.rs

                data: PhantomData<&'tcx ()>
            }

+            pub(crate) const IS_EVAL_ALWAYS: bool = is_eval_always!([$($modifiers)*]);


In #152435 I experimented with making this a field in QueryFlags instead.

The perf results were inconclusive, so for this PR I decided not to bundle that change.

This doesn't feel like a win. It introduces a new thing that has a single use. The name is similar enough to the old name that it's not any clearer.

I thought "maybe it gets used in a couple of additional places in the next commit", but no.

It made sense as part of pulling out the separate macro in another module, but if we aren't pulling out the macro then it isn't doing much anymore.

Ok. r=me with the first commit removed.

nnethercote

I like that the functions Null, Red, etc., are pulled out of the macro.

I'm less keen on having another call to rustc_with_all_queries!. This new macro feels like it belongs with define_dep_nodes!, because that also has the same pattern of "all the queries + the special dep kinds (Null/Red/...)".

Do you think there's a way this DepKindVTable stuff could be combined with the dep_kind stuff? Because we currently list the special dep kinds in two locations, which allows for them to get out of sync.

View changes since this review

Zalathar · 2026-02-12T10:52:00Z

I'm less keen on having another call to rustc_with_all_queries!. This new macro feels like it belongs with define_dep_nodes!, because that also has the same pattern of "all the queries + the special dep kinds (Null/Red/...)".

I was prepared for possible pushback on that, so I'm perfectly fine with putting it back in the central macro.

Note that we only use macro-generated code for the query dep kinds; the non-query ones all have hand-written dep-node-vtable constructors. And the macro that combines them all into one array (make_dep_kind_array!) is defined by define_dep_nodes!.

Do you think there's a way this DepKindVTable stuff could be combined with the dep_kind stuff? Because we currently list the special dep kinds in two locations, which allows for them to get out of sync.

Note that make_dep_kind_array! will enforce that the argument module contains an item for every dep kind (non-query and query), and we'll get a warning if any constructor is unused, so I don't think there can be undetected desync in either direction.

nnethercote

Second commit looks good. I don't like the first commit.

View changes since this review

nnethercote · 2026-02-12T23:26:08Z

And I still hate the "macro that produces a macro" pattern, but that's pre-existing.

Zalathar · 2026-02-13T02:41:35Z

First commit introducing IS_EVAL_ALWAYS has been removed.

@bors r=nnethercote

rust-bors · 2026-02-13T02:41:38Z

📌 Commit de04914 has been approved by nnethercote

It is now in the queue for this repository.

Rollup of 17 pull requests Successful merges: - #150551 (Compute localized outlives constraints lazily) - #150988 (Improve code suggestion for incorrect macro_rules! usage) - #152422 (Change query proc macro to be more rust-analyzer friendly) - #152496 (Fix multi-cgu+debug builds using autodiff by delaying autodiff till lto) - #152514 (Collect active query jobs into struct `QueryJobMap`) - #152520 (Don't use `DepContext` in `rustc_middle::traits::cache`) - #152528 (Support serializing CodegenContext) - #152082 (Move tests) - #152232 (Add must_use for FileTimes) - #152329 (Simplify parallel! macro) - #152444 (`-Znext-solver` Prevent committing unfulfilled unsized coercion) - #152486 (remove redundant backchain attribute in codegen) - #152519 (Fix feature gating for new `try bikeshed` expressions) - #152529 (sparc64: enable abi compatibility test) - #152548 (reject inline const patterns pre-expansion) - #152550 (Port #[prelude_import] to the attribute parser) - #152552 (Add 2048-bit HvxVectorPair support to Hexagon SIMD ABI checks) Failed merges: - #152515 (Extract `DepKindVTable` constructors to their own module)

…ercote Extract `DepKindVTable` constructors to their own module This is a fairly substantial chunk of code in `rustc_query_impl::plumbing` that mostly doesn't need to be inside a macro at all. The part that does need to be in a macro is the declaration of a named vtable constructor function for each query. I have extracted that into its own separate call to `rustc_middle::rustc_with_all_queries!` in the new module, so that dep-kind vtable construction is almost entirely confined to `rustc_query_impl::dep_kind_vtables`. There should be no change to compiler behaviour. r? nnethercote (or compiler)

rustbot · 2026-02-13T12:24:02Z

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.

Zalathar · 2026-02-13T12:24:31Z

Rebased over trivial import conflict.

@bors r=nnethercote

rust-bors · 2026-02-13T12:24:34Z

📌 Commit 1d6ef95 has been approved by nnethercote

It is now in the queue for this repository.

…ercote Extract `DepKindVTable` constructors to their own module This is a fairly substantial chunk of code in `rustc_query_impl::plumbing` that mostly doesn't need to be inside a macro at all. The part that does need to be in a macro is the declaration of a named vtable constructor function for each query. I have extracted that into its own separate call to `rustc_middle::rustc_with_all_queries!` in the new module, so that dep-kind vtable construction is almost entirely confined to `rustc_query_impl::dep_kind_vtables`. There should be no change to compiler behaviour. r? nnethercote (or compiler)

…uwer Rollup of 14 pull requests Successful merges: - #152323 (Fix ICE in borrowck when recovering `fn_sig` for `-> _`) - #152469 (Remove unused features) - #152515 (Extract `DepKindVTable` constructors to their own module) - #152555 (Port `#[rustc_diagnostic_item]` to the new attribute parsers) - #152218 (Report unconstrained region in hidden types lazily) - #152356 (Improve the `inline_fluent!` macro) - #152392 (Fix ICE in supertrait_vtable_slot when supertrait has missing generics) - #152407 (Add regression test for type_const with unit struct ctor under mGCA) - #152440 (Fix typos and grammar in compiler and build documentation) - #152536 (bootstrap: add explicit UTF-8 encoding to text-mode open() calls) - #152554 (Remove `deprecated_safe` and its corresponding feature gate) - #152556 (doc: move riscv64a23-unknown-linux-gnu to tier 2) - #152563 (Replace "bug" with "issue" in triagebot ping messages) - #152565 (fix missleading error for tuple ctor) Failed merges: - #152512 (core: Implement feature `float_exact_integer_constants`) - #152296 (Port `rust_nonnull_optimization_guaranteed` and `rustc_do_not_const_check` to the new attribute parser)

rustbot assigned nnethercote Feb 12, 2026

Zalathar commented Feb 12, 2026

View reviewed changes

nnethercote reviewed Feb 12, 2026

View reviewed changes

Zalathar force-pushed the dep-kind-vtables branch from 49fa7da to 8a54128 Compare February 12, 2026 10:59

This comment has been minimized.

Sign in to view

Zalathar force-pushed the dep-kind-vtables branch from 8a54128 to 5c80768 Compare February 12, 2026 11:16

nnethercote reviewed Feb 12, 2026

View reviewed changes

Zalathar force-pushed the dep-kind-vtables branch from 5c80768 to 295fa92 Compare February 12, 2026 23:45

This comment has been minimized.

Sign in to view

Zalathar force-pushed the dep-kind-vtables branch from 295fa92 to de04914 Compare February 12, 2026 23:52

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. labels Feb 13, 2026

Zalathar mentioned this pull request Feb 13, 2026

Rollup of 17 pull requests #152562

Merged

JonathanBrouwer mentioned this pull request Feb 13, 2026

Rollup of 14 pull requests #152571

Closed

rust-bors bot added S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. and removed S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. labels Feb 13, 2026

This comment has been minimized.

Sign in to view

Extract DepKindVTable constructors to their own module

1d6ef95

Zalathar force-pushed the dep-kind-vtables branch from de04914 to 1d6ef95 Compare February 13, 2026 12:23

rust-bors bot added S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. and removed S-waiting-on-author Status: This is awaiting some action (such as code changes or more information) from the author. labels Feb 13, 2026

JonathanBrouwer mentioned this pull request Feb 13, 2026

Rollup of 14 pull requests #152574

Open

		#[expect(unused_imports, reason = "used by doc comments")]
		use rustc_middle::dep_graph::DepKindVTable;

Uh oh!

Conversation

Zalathar commented Feb 12, 2026

Uh oh!

Zalathar Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

Zalathar Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

nnethercote Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

nnethercote Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

Zalathar Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

nnethercote Feb 12, 2026

Choose a reason for hiding this comment

Uh oh!

nnethercote left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Zalathar commented Feb 12, 2026

Uh oh!

This comment has been minimized.

nnethercote left a comment • edited by rustbot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

nnethercote commented Feb 12, 2026

Uh oh!

This comment has been minimized.

Zalathar commented Feb 13, 2026

Uh oh!

rust-bors bot commented Feb 13, 2026

Uh oh!

This comment has been minimized.

rustbot commented Feb 13, 2026

Uh oh!

Zalathar commented Feb 13, 2026

Uh oh!

rust-bors bot commented Feb 13, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

nnethercote left a comment •

edited by rustbot

Loading

nnethercote left a comment •

edited by rustbot

Loading