Planning the gcx, tcx transition

Planning the 'gcx, 'tcx transition


  • Discuss the end-state for tcx
  • Plan the steps we will take to get there and time frame


Now that we have removed the per-inference context interners, we plan to transition the compiler to a different naming scheme. This is a major shift and something we should plan carefully.

Also, it’s an opportunity to consider an alternate naming scheme – tcx and 'tcx is not known to be particularly popular.


Names for tcx

  • Given the new, query-focused compiler design, there have been proposals to rename tcx to something like QueryCx. The lifetime name 'tcx is also not particularly evocative.
    • One obvious proposal would be qcx and 'qcx though this is not obviously better.
    • q: QueryContext<'query> or something like that is also viable though longer
    • (eddyb) qx: QueryCx<'q> (if we want to make it about queries)
    • db: RustcDb<'db> (if we want to go the salsa route)

Transition plan

eddyb has a plan I sort of understand:

  • transition TyCtxt<'_, 'tcx, 'tcx>-using code first, to TyCx<'tcx> (name doesn’t matter as long as it’s unique for easy replacement later)
  • then start moving 'gcx,'tcx code one InferCtxt user at a time, by making InferCtxt creation allow both 'tcx,'tcx and 'gcx,'tcx
  • UPDATE: brute force was easier: (see PR description for how it was done)
  • what’s left to discuss is whether we want this solution

There are some question marks around timing:

  • What will it be like to rebase a major PR over these changes?
  • Any major PRs outstanding we want to block on?


  • Bikeshed :)

Key design questions


Notes from meeting

  • PRs thus far:
  • Create #61838 to serve as a tracking issue
  • So, to make the transition:
    • generally rewrite TyCtxt<..> to TyCtxt<'tcx> or TyCtxt<'_>
    • typically, rewrite TyCtxt<'_, '_, 'tcx> to TyCtxt<'tcx>
      • note that if you have TyCtxt<'_, 'tcx, '_>, rewrite to TyCtxt<'tcx>
    • replace unused lifetimes with '_, typically
    • note: when adapting your code, you should never need to introduce a new lifetime, you’re only removing them
      • if you find yourself adding a 'gcx to some impl, that’s wrong =)
  • Possible future naming:
    • We are not thrilled with TyCtxt<'tcx> and are considering some alternatives:
      • qx: QueryCx<'q>
        • couple with x being the suffix we use for “contexts” in general (this convention was adopted in trans, but not elsewhere)
      • db: RustcDb<'db> (or perhaps db: Database<'db>)
        • used in salsa, it’s the central storage for compiler state; but there are concerns that db doesn’t fit “computation”
        • if we do more modules, then RustcDb might also be ParsingDb (for parsing-related queries), TypeckDb (for type-related queries), etc
        • though there are some impl concerns around that; salsa style modules do impose
          • dyn dispatch for each call, even cache hits; or,
          • monomorphization costs
      • rs: Rust<'rs>
      • rx: Rust<'rx>
        • this is the “rust compiler”, so maybe that should be the basis of the name?
      • s: Session<'s>
        • related to existing tcx.sess
        • session of “what”?
    • Reasoning to change:
      • tcx is sort of cryptic, can we find a name that gives people a better intuition?
      • the name “tcx” suggests “type context”, but this context is far more general and is used in parts of the compiler (e.g., parsing, macros) that have nothing to do with types
  • Conclusion on naming:
    • let’s let it sit for a bit, not high priority