v0.18.0
What's Changed
- Behavior change: alias-expanded
AnnotationListentries now emit in RFC-001 §6.4 evaluation order — base alias rules first, then derived alias rules, then field-level rules. Engines that assumed the previous derived-first order (which violated §6.4) must not reorder; entries are now evaluation-ready as listed (#102, fixes #101) - Descriptor-path re-keying: because §8.3.1 ordinals key off
AnnotationListorder, same-named annotations propagated from a multi-link alias chain resolve to differentelementPath[fqn#ordinal]paths than v0.17.1 — the base-most alias's rule is now ordinal 0. Persisted descriptor paths (report keys, suppression lists, LSP bookmarks) from v0.17.1 must be re-derived.SourceMapentries moved in lockstep, and protocheck's chain reconstruction is order-independent and unaffected (#102) SourceEntry.type_chainonTYPE_REFINEMENTentries is now base-to-derived per the documented contract, and thedescriptor.protocomment now states explicitly that links are the alias chain only — the concrete base type is never a link; recover it from the first link'sTypeDecl.base_type_fqn(#102, #106, fixes #103)- Remove stale same-file-only note on
unwrapTypeAlias— cross-file annotation propagation is fully supported and now documented as such (#107, fixes #105)
Full Changelog: v0.17.1...v0.18.0