l0-v2.1.0

Dea/L0 2.1.0

Dea/L0 2.1.0 adds a supported public C runtime interface, fixes runtime correctness issues, and reorganizes both
compiler stages into cohesive modules. It preserves the L0 2.0.0 language and command-line surface.

Public C interoperability

• The new declaration-only dea_rt.h exposes supported runtime types, value macros, and externally linkable rt_*
  functions. Additional C translation units include this header without defining another copy of the runtime.
• Generated L0 C continues to include l0_runtime.h exactly once and owns the header-only runtime implementation.
  Install prefixes and distribution archives include both headers.
• Existing l0_* type names remain supported. Shared dea_* aliases and DEA_* value macros provide a common
  vocabulary for C source compiled against either L0 or L1's supported common runtime subset.
• Generated Dea calls retain their source locations in runtime traces. Direct foreign-C calls use stable external
  wrappers with the explicit fallback location <runtime>:0.
• The new C interoperability example links two additional C files and demonstrates the public header. The repeatable
  --c-source option itself was already available in L0 2.0.0.

Runtime and standard-library correctness

• vec_push_bytes safely appends from its own logical backing bytes, including interior aliases, when growth moves the
  allocation. It records the source offset before reserving storage and reconstructs the source afterward, fixing a
  use-after-free in self-appends.
• Backing-derived source ranges that include reserved but non-logical bytes, and unsupported ranges that cross into the
  backing allocation from below, fail before reserve, copy, or length mutation. Non-positive counts remain no-ops.
• Optional boolean, byte, and integer hashes now depend on semantic values rather than inactive payload bytes or C
  wrapper padding. Equal semantic values therefore hash identically across the C ABI.
• An absent optional string uses a distinct hash input domain from present optional strings, including an empty string.
  Ordinary string hashes and the present optional-string path are unchanged.
• AddressSanitizer builds poison released user payloads while they remain in the checked runtime's quarantine and
  unpoison them before allocator release. Direct stale C accesses remain observable with both retained and
  zero-retention quarantine settings.
• Expanded regression coverage checks hash declarations against C signatures, pointer-validation boundaries, generated
  runtime-call arguments, and vector aliases across checked, basic, unchecked, traced, and sanitizer configurations.

Compiler maintainability and validation

• Both compiler stages now separate CLI, semantic analysis, C emission, and backend responsibilities into explicit
  modules with canonical state owners and acyclic implementation dependencies. Cohesive recursive lowering algorithms
  remain together.
• The decomposition preserves language behavior, diagnostic codes and ordering, generated target-C behavior, ownership
  cleanup, and the self-hosting bootstrap fixed point. No production compiler module remains over 2,000 lines.
• Builtin type-name recognition is centralized within each compiler stage so token reservation, parser lookahead, and
  semantic recognition share one inventory.
• Stage 1 uses modern Python annotations and structural matching for expression inference and type formatting. Signature
  introspection remains supported, and regression tests cover annotation evaluation across import cycles.
• Python 3.14 remains the minimum. Stage 1 was also validated locally with Python 3.15.0rc2; the supported CI baseline
  remains Python 3.14. The Python modernization preserves byte-identical C output for the complete self-hosted compiler.

Editors, documentation, and delivery

• Tree-sitter rejects the obsolete case ... else default while retaining valid if ... else parsing. Standalone
  wildcard arms receive consistent highlighting in Tree-sitter, Vim, and Emacs, with TextMate regression coverage.
• Unified CI runs strict L0 documentation validation for documentation-sensitive changes and retains the
  undocumented-functions report on failure. Compiler and runtime internal API contracts now satisfy strict documentation
  coverage.
• The Docker validation image includes the L1 sources and vendored tools required by existing L0 integration tests.
• Release and documentation workflows use updated Pages actions and artifact downloads with strict digest verification.
• Live repository links, package metadata, and default provenance now identify the canonical public repository,
  dea-lang/dea.

Compatibility guidance

• Foreign C should include dea_rt.h, not the implementation-bearing l0_runtime.h. Continue to match every L0
  extern func declaration to its C definition.
• Cross-level C compatibility covers shared scalar types, strings, the four common optional types, corresponding value
  macros, and identically typed common rt_* functions. It promises source compatibility and compatible representations
  for those types, not interchangeability of L0/L1 object files or runtime binaries.
• Level-mangled records, private _rt_* helpers, tracker internals, runtime configuration macros, and packaging models
  are outside that cross-level contract. In particular, rt_time_unix, rt_time_monotonic, and rt_file_info use
  level-specific record types despite their matching function names.
• Exact optional hash results can change. Runtime hashes are deterministic for repeated equal values within one runtime
  process, but their exact values are not stable identifiers across versions, implementations, keys, or processes. Do
  not persist them or use them as compatibility fingerprints. Distinct values can still collide in the 32-bit result.
  This correction does not change equality or string-key behavior in std.hashmap and std.hashset.
• Existing L0 syntax, CLI options, public L0 types, and diagnostic codes are unchanged. Compile-only output, interface
  consumption, and external-library forwarding remain unimplemented in L0. The C header does not add L1-only APIs.

Public-surface summary

The new supported surface is the installed C declaration header, its portable aliases and value macros, and public
runtime linkage. These backward-compatible additions make 2.1.0 a minor release. The remaining changes repair runtime
behavior or improve implementation structure, validation, documentation, and delivery.

See the
full comparison between l0-v2.0.0 and l0-v2.1.0.

Release archives and generated API documentation accompany the published release. Use SHA256SUMS to verify downloaded
assets.