ELM JSON loading: generateCompiledLibrary requires resolved def.resultType, which deserialization never rehydrates (and the writer omits resultTypeName on the auto-generated context def)

[dhes]

Found on: the kmp-fhir-providers branch (5.1.0 KMP line). Third — and fatal — member of the series blocking precompiled-ELM loading; see #1827 and #1828 for the first two.

Summary

Even with #1827 and #1828 worked around, compiling the deserialized library fails: generateCompiledLibrary unconditionally dereferences each expression def's resolved resultType, but JSON deserialization only restores resultTypeName attributes — it does not rehydrate the resolved type objects — so the requirement can never be met from a round trip. Additionally, the writer does not emit resultTypeName on the auto-generated Patient context expression def, so the information is not even present in the serialized form.

This is the one that makes precompiled-ELM execution (the Library.content model clinical-reasoning and the DAK ecosystem rely on) impossible on the branch regardless of configuration.

Suggested direction

Rehydrate result types from resultTypeName during deserialization (re-resolving against the ModelManager), or relax generateCompiledLibrary to tolerate unresolved result types when EnableResultTypes was not requested.

Reproduction

dhes/cql-v5-probe @ 25030bd, Part 3 of Main.kt. The writer-side omission is verifiable by inspecting the emitted JSON for the context def.