​​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