Repository navigation
Architectural groundwork for expansion-time evaluation #620
Description
| Metadata | |
|---|---|
| Contact | @oli-obk |
| Team(s) | compiler (@petrochenkov), types (@oli-obk) |
| Goal document | 2026/expansion-time-evaluation |
| Funding contact | RustNL |
Summary
Lay the architectural groundwork for functions that can be evaluated during macro expansion. This speculative work focuses on "queryifying" the resolver and implementing a restricted trait solver mode, enabling future language features like macro fn and compiler-integrated interop tools.
This issue is intended for status updates only.
For general questions or comments, please contact a goal owner or post in the Zulip topic.
Reacted by Luca Palmieri, Jeff Parsons and Jeff Parsons
Activity
tomassedovic commentedon May 5, 2026
This issue is intended for status updates only.
For general questions or comments, please contact the owner(s) directly.
Auto merge of #138995 - oli-obk:split-resolver, r=petrochenkov
Auto merge of #138995 - oli-obk:split-resolver, r=petrochenkov
Auto merge of #138995 - oli-obk:split-resolver, r=petrochenkov
oli-obk commentedon Jun 3, 2026
First update:
I did the groundwork refactorings for avoiding
node_id_to_def_idsplitting into a per-owner table being a perf regression. Not only did that succeed, but it turned out to be a (small) performance improvement to do those refactorings.The refactorings in question:
After those, the split PR was perf neutral
Which was than fairly easy to follow up with
which leaves the remaining fields
partial_res_mapextra_lifetime_params_maplint_buffer(probably easy)delegation_infosdisambiguators(easy, but may be perf-relevant, we'll see)extra_lifetime_params_mapis somewhat blocked on rust-lang/rust#156508 to finish splitting the resolver's owner-relevant maps into per-owner ones, but once crater finishes on that I'm going to start a T-types FCP. In parallel I can still work on the follow-ups, but probably can't land them due to perf reasons, will try. But def will work on the other fields in paralleloli-obk commentedon Jul 8, 2026
Not too much directly for this goal, although in parallel I have been pursuing groundwork to unlock making the delegation HIR queries have cycle errors if they are cyclic instead of requiring an extra cycle detection pass that needs more global information
'staticrust#156508 was approved by the types team and will land soonThe most important change is
which splits the hir_crate query into per-owner queries. While on its own it doesn't allow for any incremental improvements, we can now lower the HIR of individual owners without having to have all other owners also lowered. In theory now the lowering of one HIR owner can depend on anothers' HIR
Rollup merge of rust-lang#159226 - oli-obk:extra_lifetime_params_map,…
Rollup merge of rust-lang#159226 - oli-obk:extra_lifetime_params_map,…
Rollup merge of rust-lang#159226 - oli-obk:extra_lifetime_params_map,…
Rollup merge of #159226 - oli-obk:extra_lifetime_params_map, r=petroc…
Auto merge of #138995 - oli-obk:split-resolver, r=petrochenkov
oli-obk commentedon Sep 10, 2026
I ran into some warts that made it hard to finish the split of resolver data for ast lowering. The remaining issues all related to use statements, so I am attempting to keep use statements in their tree form (that they have in AST), so that the HIR doesn't have to change anything about that. This has some complications, too, but it is generally a cleanup and allows for further cleanups down the road: rust-lang/rust#161349
I'm now also working on adding a new trait solver mode that allows us to run the trait solver (and thus also some things depending on it) without triggering ast lowering. This works by restricting the trait solver in that mode to only look at things from upstream crates and ignore all impls from this crate.
Auto merge of #161349 - oli-obk:unflatten-use, r=petrochenkov
Auto merge of #161349 - oli-obk:unflatten-use, r=petrochenkov
Auto merge of #161349 - oli-obk:unflatten-use, r=petrochenkov
oli-obk commentedon Oct 9, 2026
In a local branch I now have basic trait solving working from within a builtin macro. You can use it to check if a type from an upstream crate implements a trait from an upstream crate (including specifying different generic parameters for the trait (e.g.
bool: PartialEq<bool>vsbool: PartialEq<u32>)I'm now working on a small demo showing what you can do with it in practice.