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