-
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
test java codegen with strange type / module names using daml-lf directly #2
Comments
@francesco-da: regarding point 1) " strange names (dollars, keywords, etc)", other than keywords in the target language, how can we even get strange names. |
|
We don't intend on writing DAML-LF directly for java codegen tests. |
CHANGELOG_BEGIN CHANGELOG_END NormalizeRollbackSpec, WIP WIP2 adapt to asVersionedTransaction first stab at traversal for normalize-rollbacks... implement normalization rule #1 adapt existing testcase for rollback normalization rule #1 pluralize spec filename temp disable rollback normalization methodically test normalization rule #1 lots more tests spec: check all 3 norm conditions cleanup test/Shape code a bit implement normalization rules #2 and #3 (using canonical types) and enable tests add some comments and some 8020 todo markers
* Normalize rollbacks: first draft CHANGELOG_BEGIN CHANGELOG_END NormalizeRollbackSpec, WIP WIP2 adapt to asVersionedTransaction first stab at traversal for normalize-rollbacks... implement normalization rule #1 adapt existing testcase for rollback normalization rule #1 pluralize spec filename temp disable rollback normalization methodically test normalization rule #1 lots more tests spec: check all 3 norm conditions cleanup test/Shape code a bit implement normalization rules #2 and #3 (using canonical types) and enable tests add some comments and some 8020 todo markers * add 2 more testcases from Sofia * ensure tx produced when normalizing rollbacks has increasing node-ids when listed in pre-order * enable rollback normalization in interpreter * manage state functionaly for the created tx (counter & node-map) * un-nest sub defs from normalizeTx (we can because we removed the mutable state) * rename: force* --> push* * introduce CPS for push functions * introduce trampolines for push functions to be stack safe * one more bounce * ensure generated node-ids start from 0 * test that transaction node-ids start from 0 * add commets about pass1/2; move makeRoll (part of pass 1) earlier in file * intro CPS for pass-1 over original tx * intro trampolines for pass-1. everything is stack safe now * clarify comment * remove make stack-safe todo * be more private * factorize/share Trampoline implementation with previous implementation in speedy.Anf * prefer Vector over List, for better algorithmic complexity * make Trampoline private to lf
Part of #9947, building on the key visibility checks from #10136 This PR adds a divulgence warning inside the traceLog. I wasn't sure whether: 1. these warnings should be kept in a separate structure from the traceLog, and therefore transmitted separately, or 2. these warnings should be kept together with traces, but the severity should be tracked and also transmitted over grpc, and warnings should be logged as warnings instead of as debug messages, or 3. these warnings should be kept together with traces, but logged as warnings instead of debug messages, 4. these warnings should be treated exactly like traces I'm leaning toward #2, but this PR implements #3. This PR tests the warning via the script service tests. changelog_begin changelog_end
Part of #9947, building on the key visibility checks from #10136 This PR adds a divulgence warning inside the traceLog. I wasn't sure whether: 1. these warnings should be kept in a separate structure from the traceLog, and therefore transmitted separately, or 2. these warnings should be kept together with traces, but the severity should be tracked and also transmitted over grpc, and warnings should be logged as warnings instead of as debug messages, or 3. these warnings should be kept together with traces, but logged as warnings instead of debug messages, 4. these warnings should be treated exactly like traces I'm leaning toward #2, but this PR implements #3. This PR tests the warning via the script service tests. changelog_begin changelog_end
* Add divulgence warning and test in script service. Part of #9947, building on the key visibility checks from #10136 This PR adds a divulgence warning inside the traceLog. I wasn't sure whether: 1. these warnings should be kept in a separate structure from the traceLog, and therefore transmitted separately, or 2. these warnings should be kept together with traces, but the severity should be tracked and also transmitted over grpc, and warnings should be logged as warnings instead of as debug messages, or 3. these warnings should be kept together with traces, but logged as warnings instead of debug messages, 4. these warnings should be treated exactly like traces I'm leaning toward #2, but this PR implements #3. This PR tests the warning via the script service tests. changelog_begin changelog_end * scalafmt * Address Moritz's review * Rename traceLog.add to traceLog.addDebug * fix test * Add test using exercise * add single transaction test
) * Try and improve the explanation of compatibility test exclusions CHANGELOG_BEGIN CHANGELOG_END * Fix scenario description * Attempt #2 at trying and improving the explanation of compatibility test exclusions
…n filter. Attempt #2 CHANGELOG_BEGIN CHANGELOG_END
…1704.0.v67e3d1e3/3.0.0-snapshot.20240115.12269.0.vee57276e (#18183) * update canton to 20240115.12269.0.vee57276e/2.9.0-snapshot.20240115.11704.0.v67e3d1e3/3.0.0-snapshot.20240115.12269.0.vee57276e tell-slack: canton * Adapt changes after changing of Decode.assertDecodeInfoPackage signature * Fix canton-3x Bazel rules for 'Moved http health to node and migrated health based tests to X nodes #16415' * Fixed GetEventsByContractIdResponse misalign in v2. * Removed unused dependency. * Removed unused dependency #2. * Fix daml3-script upgrade querying. Disable the test as more work needed. --------- Co-authored-by: Azure Pipelines Daml Build <[email protected]> Co-authored-by: Tudor Voicu <[email protected]> Co-authored-by: Yves Geissbuehler <[email protected]> Co-authored-by: Andreas Triantafyllos <[email protected]> Co-authored-by: Samuel Williams <[email protected]>
* update canton to 20241020.14357.va37ef963 tell-slack: canton * Changes for getActiveContracts. * Changes for getActiveContracts #2. * Improve terminology in upgrades error messages (#20053) * Drop unused NewVariant errors, add NotAtEnd errors, improve messages * Refactor error printing slightly * Update error message expectations in lsp-tests & damlc-upgrades * Add metadata to pkg IDs & drop upgrading/upgraded in upgrade err msgs * Replace "Variant" with "Constructor" where appropriate * lint * Adjust filepaths, expectations for Variant -> Constructor rename * Fixes for field names and test expectations given added metadata * Increase grpc message max log length * lint * Move & rename PkgIdWithMeta, make name/version non-optional * Use shared variable instead of calling PkgIdWithNameAndVersion thrice * lint --------- Co-authored-by: Azure Pipelines Daml Build <[email protected]> Co-authored-by: Andreas Triantafyllos <[email protected]> Co-authored-by: dylant-da <[email protected]>
there are various edge cases in the java codegen that we cannot test easily or at all using a
.daml
file. for example i do not believe we can currently generate type names with dollars in them from.daml
.before it was very hard to write DAML-LF directly, but it's actually much easier now thanks to @remyhaemmerle-da 's parser. see https://github.com/DACH-NY/daml/blob/2766d13da75fcf7b1e08f00fbc02d6891aa53645/daml-foundations/daml-lf/interface/src/test/scala/com/digitalasset/daml/lf/iface/TypeSpec.scala#L75 for an example test where i use the type parser.
problematic tests we should make sure to test:
Foo:Bar
andFoo.Bar:Baz
-- this is now forbidden as per DAML-LF collision restriction, see https://github.com/DACH-NY/daml/blob/c876df419ddcfb13b4cc445e9f014c8ac6f6642a/daml-lf/spec/daml-lf-1.rst#id31 . specifically, the typeFoo:Bar
would conflict with moduleFoo.Bar
Foo:Bar
resulting in classFoo
in the default namespace, rendering it effectively unusable (cannot be used in another Java file). -- not applicable anymore because now we create a package per module, rather than a class per module.and anything else @stefanobaghino-da , @gerolf-da , or @mariop-da can think of.
The text was updated successfully, but these errors were encountered: