TASTy Binary Compatibility and Long-Term Stability Constraints

Question

Typed Abstract Syntax Trees (TASTy)
Scala 3 utilizes TASTy files to store serialized typed ASTs, enabling more precise type checking across module boundaries compared to traditional JVM signatures. This mechanism allows the compiler to resolve high-level types, such as union and intersection types, when consuming external dependencies.

Cross-Version Interoperability
While TASTy facilitates cross-compilation between compatible compiler versions, there is uncertainty regarding the stability guarantees for these files across major releases. Specifically, it is unclear if a library compiled with an early Scala 3.x version will remain binary compatible with significantly later releases without necessitating a full recompilation of the dependency graph.

What are the specific versioning constraints that determine TASTy compatibility between major compiler releases? Under what conditions does the TASTy format require a full recompilation of all upstream dependencies to maintain stability?

Tasadduq Burney · Answer

TASTy format versioning and cross‑compiler compatibility
Scala 3 stores compiled module information in TASTy files, which carry a format version produced by the compiler that built them. The consuming compiler must support that version to read the file.
Asymmetric read capability
A newer Scala 3 compiler can read TASTy files produced by an older compiler in the same 3.x line, but the reverse is not guaranteed. This asymmetry means that upgrading the compiler generally does not break consumption of previously compiled libraries, provided the TASTy format version does not exceed the consumer’s supported range.
When full recompilation becomes necessary

Experimental or nightly compiler features: TASTy files marked experimental are rejected by stable releases. Libraries built with such features require recompilation of all upstream dependencies when consumed by a stable compiler.
  Minor TASTy format bumps: Within a 3.x release series, a minor format version increase may cause older compilers in the same line to refuse the file, effectively requiring a recompilation of the affected modules.
  Major version transitions: A hypothetical Scala 4 release would be expected to break TASTy compatibility, mandating a full dependency‑graph recompilation, analogous to the Scala 2 → 3 transition.

Standard library coupling
TASTy references symbols from the scala-library version it was compiled against. The 3.x stdlib series is designed to be backward compatible at runtime, but the compile‑time type reference still depends on the library version used during production.
Verification steps
# Check your compiler's TASTy support version
scalac -version

# Attempt to compile a project using an older 3.x compiler against a library built with a newer 3.x release
# Observe for unsupported TASTy version error
If your library was built with experimental or nightly Scala 3 tooling, the compatibility rules change—full upstream recompilation becomes necessary. For a concrete diagnosis, sharing the producer and consumer compiler versions is the single detail that determines whether the issue falls under experimental TASTY handling or a format‑version bump.

TASTy Binary Compatibility and Long-Term Stability Constraints

Typed Abstract Syntax Trees (TASTy)

Cross-Version Interoperability

1 answer

TASTy format versioning and cross‑compiler compatibility

Asymmetric read capability

When full recompilation becomes necessary

Standard library coupling

Verification steps

Your perspective belongs here.

0 question comments