Daml.Codegen.Testing.Conformance 0.5.0-preview.3

Daml.Codegen.Testing.Conformance

Compiled C# generated by daml-codegen-csharp from the conformance corpora, plus each corpus DAR embedded as a resource. Consumers (typically ledger-client integration test suites) round-trip these types against a real Canton participant to prove codegen output works end-to-end. Not for production use.

ConformanceCorpus.OpenDar() returns the embedded rich-types DAR to upload to a participant; ConformanceCorpus.OpenDar(ConformancePackage.ContractKeys) returns the contract-key one, and ConformanceCorpus.OpenDar(ConformancePackage.DefaultTarget) the one built with no Daml-LF target requested.

Generated types are emitted one namespace per Daml module, all under Daml.Codegen.Testing.Conformance: RichTypes for the first corpus, ContractKeys and KeyBuilders for the second, DefaultTarget for the third. RichTypes was spelled Richtypes before 0.5.0-preview.2, and the rename is case-only, which Roslyn does not forgive — a consumer holding using Daml.Codegen.Testing.Conformance.Richtypes; stops compiling until the spelling is corrected, as does a <Compile Include … Link="Generated\Richtypes\…"> path, the directory having been renamed with the namespace.

RichRecord carries the primitive, collection and nominal shapes. TypeCorners carries the harder ones: parameterized records and variants (Box, Slot), GenMap keyed by Party and by Int, Either, Tuple2/Tuple3, a recursive record (Branch), an Optional nested directly inside an Optional (maybeMaybeNote, held as Optional<Optional<string>>) and one separated from its outer Optional by an intervening record (nestedNote), an Optional over a record's own type variable (Crate), held as Optional<TA> because C# nullable syntax cannot spell that position, an Optional carried by an Either arm (noteOrRank, held as Either<Optional<string>, long> for the same reason), and the Numeric scale extremes 0 and 37 — the last of which the generated code exposes as decimal, so values needing more than 28 fractional digits are not representable. The Holding interface carries choices as well as a view. Keyed templates live in the second corpus, ContractKeys, which is built at Daml-LF 2.3 because no earlier version can express a contract key: Account keys on a record of two payload fields, Holiday on a record whose field comes from a nested projection, Schedule on a record built by a helper in a second module, KeyBuilders — so its ScheduleKey, and the ScheduleView beside it, are emitted under Daml.Codegen.Testing.Conformance.KeyBuilders and need a using of their own alongside the one for ContractKeys — and Steward on a bare Party. Each generated active contract carries a Key slot read off the created event, and each choice has a <Choice>ByKeyCommand builder beside its <Choice>Command one.

A third corpus, DefaultTarget, carries a single template (Note) compiled with no Daml-LF target requested, so it ships the version damlc picks for a project that asks for none — the version a scaffolded project actually produces. Its generated types are compiled and shipped like the other two, so that version is covered on the code-generation path and not only on the reading one.