Match query key types as $K:tt instead of $($K:tt)*

[Zalathar]

When query-plumbing macros match on a query key type, they currently have to perform a clunky match on $($K:tt)*, instead of the more obvious $K:ty.

Switching to $K:ty is currently not feasible, because that would prevent us from inspecting the specific key type in a helper macro that decides whether to replace $K with impl IntoQueryParam<$K>, if the key type happens to be DefId or LocalDefId.¹

However, we can switch from $($K:tt)* to the simpler $K:tt if we modify the proc-macro to always emit key types surrounded in parentheses, guaranteeing that they always form a legal type that is also a single token tree.

(In some of the helper macros, this PR does switch to $K:ty because the inner token structure is not needed there.)

Background on impl IntoQueryParam<K>

Of the ~300 queries currently used by the compiler, about 100 have a key type of DefId or LocalDefId. For those two key types, the query plumbing macros have special logic to declare the corresponding query methods as taking impl IntoQueryParam<DefId> or impl IntoQueryParam<LocalDefId> instead. That allows callers to pass IDs that are actually strongly-typed wrappers for a subset of DefId/LocalDefId², without having to explicitly convert at the call site.

There are arguments for or against doing that kind of trait-based argument conversion,³ but there are enough call sites currently relying on it that stopping would be a pretty substantial change.

Meanwhile, there are good reasons to not want to extend that practice to the other ~200 queries that don't need it. Auto-converting to DefId is common enough to arguably be worth it, whereas cluttering the real signatures of query methods that don't need auto-conversion adds real friction⁴ for almost no benefit.

---

The first commit is a general cleanup of rustc_macros::query that makes the subsequent changes more readable. It could be merged on its own if desired.

---

• This PR is a potential alternative to some of the impl IntoQueryParam changes in Clarify aspects of query macros #152779.

r? nnethercote

Footnotes

1. In macro-rules macros, any input matched by something that isn't tt is subsequently treated as an opaque unit, whose sub-tokens cannot be inspected. ↩

2. Example conversions include LocalDefId → DefId, ModDefId → DefId, and LocalModDefId → LocalDefId. ↩

3. E.g. callers could just write .into() explicitly instead. ↩

4. Parameters involving conversion traits have less helpful type inference, less helpful error messages, and complicate otherwise-straightforward signatures as seen in documentation or IDE hover tips. ↩

[nnethercote]

The current code implements the query-key-conversion stuff partly in the define_callbacks and query_helper_param_ty macros, and partly in the type system (IntoQueryParam).

#152779 eliminates the macro parts, so it is fully in the type system. And we end up using $K:ty, like you'd expect, and was my original goal when I started looking into this.

This PR spreads the complexity more: partly in the proc macro, partly in define_callbacks and maybe_into_query_param macros, and partly in the type system. All this and we end up with $K:tt, which is not as nice as $K:ty. Not an improvement, IMO.

--

About #152779's, you said "it clutters the signature of every single query method in a way that adds real friction." I don't understand what that "friction" is.

[Zalathar]

About #152779's, you said "it clutters the signature of every single query method in a way that adds real friction." I don't understand what that "friction" is.

It wrecks type inference, it wrecks error messages, and it wrecks documentation.

That's not something I want to inflict on contributors for hundreds of methods that don't need it, especially if the only payoff is being able to write $K:ty instead of $K:tt in some query plumbing macros.

[nnethercote]

The first commit is good. Just yesterday I was puzzling over the difference between key and arg, so I like the renaming and the explanation of the query anatomy.

The second commit increases coupling between the proc macro and the declarative macro in a way I don't like. I guess we'll just have to live with $($K:tt)*.

[Zalathar]

• I've extracted the cleanups to Clarify some variable names in the query proc-macro #152846.