Closed stefanobaghino-da closed 2 years ago
I had a look in past version to check whether this is some kind of regression. The earliest SDK version which which the library compiles is 1.11.0. The error was already there at that point. I also tried to use the latest version of the library instead of an old branch. The error is still there. I'll try to create a minimal repro now.
https://github.com/digital-asset/daml/pull/13571 "hides" the problem on the library itself but the occurrence on this bug can still be verified by using it as part of a project where the contingent claims are part of a template definition. Investigating it now.
Next steps:
contingent-claims
library in a templateIf it compiles: the ticket can be closed. If it doesn't compile: continue the investigation.
@matevarga-da If the customer just ran the codegen on library the next version should fix the problem. If the customer is actually using this as a library and running the codegen on the overall artifact using the library, please stand by and watch this ticket for further updates. The relevant ticket is https://digitalasset1.lightning.force.com/lightning/r/Case/5004x00000AZaYTAA1/view
@cocreature I confirmed that this does not demonstrate serializable
being set on any nonserializable data type definitions in the dalf. ContingentClaims.Claim.Serializable.ClaimF
is serializable.
Some investigation notes: generateToValueForRecordLike
seems to do the right thing. At a glance escapedNestedTypeVarNames
seems the most likely to be missing the t
type variable in its traversal, or possibly distinctTypeVars
is excluding it for being "equal" to x
somehow.
thanks for the confirmation.
I just realized that https://github.com/digital-asset/daml/pull/13571 performs the transitive closure computation at a DAR level (unless I'm mistaken). Is this enough? Could the codegen be run with two DARs, one with data declarations which are used in templates defined in another?
I just realized that #13571 performs the transitive closure computation at a DAR level (unless I'm mistaken).
I believe you're mistaken. configureCodeGenScope
makes a Seq[Interface]
from all darFiles
and an EnvironmentInterface
from that (all as intended), and finds the dependencies from that.
@matevarga-da #13658 follows up the above with a fix to the original noncompiling code, so it will work regardless of whether ClaimF
is used in a template.
Steps to reproduce:
This will cause the following errors to be reported:
Support case: https://digitalasset1.lightning.force.com/lightning/r/Case/5004x00000AZaYTAA1/view