Rust 2018 Compiler End-to-end queries
- biggest thing to move to the query engine: the HIR
- actually easier to get parsing?
- parse(file) → AST
- HIR Map is .. um .. used a lot
- what should queries be?
- it would be nice to not have all the custom tracking code
- Option 1:
- hir(crate) → HirMap
- Option 2:
- hir(item) → HirMap // for the item
- a few kinds of items but not much of a need for separating them:
- variants
- trait items
- impl items
- foreign items
- maybe we can flatten these into “Item”?
- nested constants:
- [T; N] -- maybe we pull N out to one of these items?
- something with closures :)
- currently they have their own BodyId
- lowering is an atomic thing
- crate_hir_map — does lowering
- item_hir_map — extracts individual bits
- item_bodies — that sort of thing
- krate →
- move the maps into HirMap
- “krate” is just the root module (it’s an Item)
- exported_macros
- what about uses of visitor::walk_krate ?
- not a real problem, existing system works fine
- name resolution + macro expansion
- name resolution is a fixed point pain in the !@#! but --
- if only fn bodies have changed, should be able to reuse **that**
- want to be able to hash fn bodies separately from the things that contribute to global name resolution
- parsing can be made relatively granular
- hir shim:
- self.tcx.hir().foo(hir_id) → maps to a query
- killing NodeId
- Save Analysis is a major consumer?
- Need to keep a map
- try to keep it out of the reach of the rest of the compiler
- question:
- do we want to commit to keep the cache around
- measure the impact on memory usage??
- SVH — what is going on with this thing
- HirMap’ing computes the SVH by combining all hashes of all the items
- used to see if anything in the crate has changed
- can integrate that into crate_hir_map
- also includes command-line arguments, upstream SVH codes, and other nonsense