interior-mutability-list.md

This list comes from reading over Zoxc's commit here:

https://github.com/Zoxc/rust/commit/12756affd4ab4467da80ac2e18bde50a8a1c3ede#diff-c8a6d543f758cb294320bcac3b5268aeR885

complete list

• dep-graph
• hir-map (inlined bodies)
• session:
  • lint-store
  • recursion-limit
  • entry-fn etc
  • features
  • etc
  • next-node-id
• caching
  • MIR pred cache
  • trait system:
    • selection cache
  • metadata decoding
• type interning etc
• other:
  • derive_macros
  • stability_interner
  • interpret_interner
  • layout_internrer
• lazy computation
  • all_traits (and this too)
• counters
  • layout-depth
• trans back-end
  • tx_to_llvm_workers
• dep-graph
  • current diagnostics
  • cnum_map
  • caches lazilly populated during decoding
• MIR stealing
  • probably best replaced with the linear queries discussed in #41710
• record_time
  • used to do little "spot measurements" of execution time for particular things
  • maybe best replaced with perf anyway
• error emitter
• crate metadata store
• codemap
• filemap
• set of active features
• parser session

core structures that will require synchronization

• dep-graph
• perf-stats
  • these are just hacky little counters and things
• type interning
  • the global one, anyway -- not sure about inference context?
• stability_interner
• interpret_interner
• layout_internrer
• tx_to_llvm_workers
  • this is just a channel, seems fine

needs to be based on the stack

• layout-depth
  • I think this really wants to walk the stack and count the number of active layout frames, rather than being a counter. Or it could be carried along with the stack.

not sure how to handle

• optimization fuel
  • this whole premise seems to require a single thread
  • we should just lock to one thread if optimization fuel is given I guess to force deterministic ordering

things that can be refactored away (and some notes on how)

• hir-map (inlined bodies)
  • I think that @oli-obk's work on miri makes this go away
• session: (in general, this should go away and become the tcx)
  • buffered-lints
    • iirc, the only reason this exists is because the tcx isn't around to produce the lint-level map query yet
  • recursion-limit
    • move to query
  • entry-fn, plugin crap, etc
    • move to query
  • crate disambiguator
    • move to query
  • features
    • move to query
  • etc
• caching
  • MIR pred cache
    • this is linked to a MIR and cleared when it changes. Now that MIR moves linearly through the system, we can recode I suspect to use &mut maybe? Or maybe make the computation more explicit (e.g., the cache is populated via explicit action, and then queried, and if it is not populated we get a panic). Synchronization here seems really wasteful in any case.
  • trait system
    • ties in to the WG-traits plans; I would like to completely revamp how trait caching works anyway.
    • but something with locks is prob ok for now
• all_traits (and this too)
  • move to query
• MIR stealing
  • probably best replaced with the linear queries discussed in #41710
  • stuff like this makes me nervous
• set of active features
  • move to query -- come on, are you kidding me??

unclear, would like feedback

• error emitter, crate metadata store, codemap, filemap, parser session

  • the main reason they use refcell so extensively is because they are old and mutablity in Rust used to be far easier. But maybe it'd be nice to be able to parse source files in parallel, in which case some amount of synchronization is needed? I'd love to see more of this stuff pushed back into queries though. Thoughts would be welcome here.
  • cc @petrochenkov, @eddyb, @estebank

• session

  • lint-store etc
    • surely this doesn't have to be as wacky as it is
    • cc @manishearth
  • next-node-id
    • no idea what this is all about

• derive_macros

  • I have no idea what it is in here really. cc @alexcrichton?