-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replace experimental interface primitives with proper LF primitives #12678
Conversation
6068a69
to
edc4e85
Compare
daml-lf/archive/src/main/protobuf/com/daml/daml_lf_dev/daml_lf_1.proto
Outdated
Show resolved
Hide resolved
d561695
to
6934849
Compare
fac8858
to
5e086ca
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice! One comment on the names (sorry for bikeshedding that), looks good otherwise.
I think as a next step (fine with me to have that in a separate PR) we should test this thoroughly. Specifically we need at least the following tests:
- First, you probably need to extend the Daml-LF parser to support these primitives so you can actually write steps
- Test that the decoder rejects these in older LF versions and accepts them in 1.dev.
- Add tests for the Daml-LF typchecker
- Add SBuiltin tests for the corresponding builtins.
Probably missed something but @remyhaemmerle-da can surely remind us of that.
daml-lf/archive/src/main/protobuf/com/daml/daml_lf_dev/daml_lf_1.proto
Outdated
Show resolved
Hide resolved
daml-lf/validation/src/main/scala/com/digitalasset/daml/lf/validation/Typing.scala
Show resolved
Hide resolved
daml-lf/archive/src/main/protobuf/com/daml/daml_lf_dev/daml_lf_1.proto
Outdated
Show resolved
Hide resolved
daml-lf/archive/src/main/protobuf/com/daml/daml_lf_dev/daml_lf_1.proto
Outdated
Show resolved
Hide resolved
daml-lf/archive/src/main/protobuf/com/daml/daml_lf_dev/daml_lf_1.proto
Outdated
Show resolved
Hide resolved
a22bb1a
to
939a498
Compare
SBInterfaceTemplateTypeRep(ifaceId)(compile(env, body)) | ||
case ESignatoryInterface(ifaceId, body @ _) => | ||
val arg = compile(env, body) | ||
SBSignatoryInterface(ifaceId)(arg, arg) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this should do the trick so SBResolveVirtual
gets the argument twice, but I'm not quite sure. Could you please tell me if this makes sense? @remyhaemmerle-da @sofiafaro-da @cocreature
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks sensible to me. We may want to see if passing the argument twice is really the best way to address this (for these an for other primitives) but definitely not in this PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this is good enough for the MVP.
…Signatory,Observer}
…TORY,OBSERVER} (haskell)
…TORY,OBSERVER} (scala)
746180c
to
35f8872
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, thank you!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
now that this is green, I'll
|
00bac8a
to
af3ad07
Compare
from 130 to 125, reason the test is currently flaky (It fails around 20% of the time). Surprisingly, #12678 seems to have increase the stack usage for the type checker. CHANGELOG_BEGIN CHANGELOG_END
DA-GHC PR: digital-asset/ghc#100
Pull Request Checklist
CHANGELOG_BEGIN
andCHANGELOG_END
tagsNOTE: CI is not automatically run on non-members pull-requests for security
reasons. The reviewer will have to comment with
/AzurePipelines run
totrigger the build.