Restructuring our compiler architecture: first slice of the semantic-database transition

[dannymeijer]

We are approaching the point where incremental compiler cleanups are no longer enough.

Over the last several releases, the compiler has accumulated semantic facts in too many partially-overlapping places:

• module resolution state
• symbol tables
• typechecker snapshots and bridge structs
• Rust inspection/interop caches
• downstream helper lookups and fallback logic

That has a recurring cost:

• the same fact gets rediscovered in multiple places
• backend and tooling paths do not always consume the same semantic truth
• missing or partial data tends to degrade into local fallback branches
• implementing new surfaces often requires touching many files and adding glue code instead of extending one clear semantic model

At this point, continuing to evolve the current architecture as-is looks less convincing than it used to.

Proposed direction

The current direction we are considering for the first 0.5 architecture slice is:

• introduce a per-snapshot CompilationSession
• move toward session-owned semantic facts
• introduce stable semantic IDs for modules, symbols, expressions, and related analysis entities
• give downstream compiler stages a small query-oriented semantic surface instead of requiring them to rediscover facts
• start carving out a clearer analysis center in the codebase rather than keeping the root compiler crate as the long-term implementation monolith

In other words, the goal is not “add a new wrapper object.” The goal is to begin a real semantic-database transition.

What this is not

This is not a proposal for:

• a process-global compiler singleton
• a big-bang rewrite of the whole compiler in one release
• immediately committing to a query framework like salsa
• shifting user-facing language behavior in 0.5

The likely first step is more conservative than that: start with a custom semantic database around CompilationSession, prove the ownership model, and then decide later whether a stronger query framework is warranted.

What 0.5 should prove

A good first slice should prove a few things in real code:

• we can move at least one meaningful class of semantic facts behind session ownership
• at least one high-friction compiler path becomes materially simpler
• codegen and tooling can start consuming semantic queries instead of re-deriving frontend meaning
• the root crate can begin shrinking as a long-term implementation monolith

If that does not happen, then the transition is probably too cosmetic.

Open questions

These are the main questions where outside eyes would be useful:

1. Does the problem statement ring true from your experience with the codebase?
2. What should the first owned fact class be?
   Candidates include module/import facts, symbol facts, or typed semantic facts.
3. What would make a first CompilationSession slice feel real instead of decorative?
4. Which current compiler path would be the best proving ground for the first migration?
5. What failure modes or migration risks are missing from this framing?

There is already a tracking issue for the eventual 0.5 work:

• chore - begin compiler semantic-database transition around CompilationSession #224

This discussion is meant to shape that work before it becomes a concrete implementation push.