* update canton to 3.0.0-snapshot.100000000.20240214.12557.0.v052dc804
tell-slack: canton
* Fix Canton code drop
---------
Co-authored-by: Azure Pipelines Daml Build <support@digitalasset.com>
Co-authored-by: Tudor Voicu <tudor.voicu@digitalasset.com>
We can currently have a problem where we can generate code that the java compiler chokes on.
This occurs when we have a generated class with a field, say `public final Integer foo;`, and it needs to call the `jsonDecoder` static method of a class under a package which begins with "foo", e.g. `foo.bar.Baz.jsonDecoder()`
Java sees the `foo.bar` and interprets that as an attempt to access the `bar` field on the local `foo` variable, and fails with `symbol not found`, not understanding that `foo.bar` is simply the package qualifier of the `Bar` class. When hand-writing code, we can avoid this by importing `foo.bar.Baz`, and then calling the method with `Baz.jsonDecoder()`, but when generating code, the JavaPoet library seems to opt for using fully qualified references to these static methods, which is when we can hit the problematic expressions.
This workaround generates a class nested within `Baz` a la
public static class JsonDecoder$ { public JsonLfDecoder<Baz> get() { return jsonDecoder(); } }
which simply forwards the call on. However it means that we can avoid the ambiguious parsing context at the call side by invoking the method via `new foo.bar.Baz.JsonDecoder$().get()`. Using the `new` keyword clarifies that the next thing is a type, and javac correctly resolves `foo.bar` as a package name.
I benchmarked the changes with `bazel run language-support/java/codegen:from-json-bench` and there was no appreciable impact on performance.
We had previously avoided this issue by using `.simpleName` on the class used for `jsonDecoder()` to explicitly drop the package name, but that won't work once we start supporting decoding of choice arguments and results, as the relevant types typically won't have already been imported.
This workaround would be unnecessary if JavaPoet would reliably import all referenced types, and then refer to the class name unqualified. It would also be unnecessary if javac were a bit smarter about its parsing. However as of this PR, that does not seem to be the behaviour.
* Add resolution via artifactory, handle HTTP errors
* Replace origin with wrapErr in resolveReleaseVersionUnsafe
* Handle broken connections (e.g. no internet)
* drop comment, fix foldMap id to fold
* remove debugging writeFile calls
run-all-tests: true
* Rename partial field damlPath to damlPathUnsafe and add safe function
* support multiple possible installation locations
* update alternatives
* Wrap CouldNotResolveReleaseVersion into AssistantError in unsafe resolve
* update canton to 3.0.0-snapshot.20240208.12514.0.v683212b4
tell-slack: canton
* commit to cherry-pick on canton upgrade
---------
Co-authored-by: Azure Pipelines Daml Build <support@digitalasset.com>
Co-authored-by: Marcin Ziolek <marcin.ziolek@digitalasset.com>
I'd like to remove `dev-env`. It's served us well, but its original
ambitions were to go way beyond a simple `nix-shell` equivalent, and now
that it's all we're using it for it doesn't really add much anymore.
Using a standard nix-shell setup would reduce the complexity of this
repo and make it easier for other developers to jump in. It would also
somewhat reduce the dev-env verbosity, which is a minor annoyance.
This is, however, a big change, and I don't think trying to do it in one
go is a great idea. So instead I'm setting a foundation in this PR and
plan to move step by step over several follow-up PRs. In this one I just
add a small default nix-shell configuration and add it to `.envrc`. In
follow-up PRs, I'll be moving paclages over from the dev-env
configuration to the nix shell, up to the point where dev-env is just an
empty shell that we can easily remove.
This PR also serves as a not-so-implicit way of gathering support for
this plan.
* remove the featurePackageUpgrades flag from the compiler
* fix //compiler/damlc/tests:platform-independence-dar-hash-file-matches
* fix Daml[23]ScriptTestRunner
* update canton to 3.0.0-snapshot.20240207.12502.0.va204c7cf
tell-slack: canton
* Fix DamlLfVersionToProtocolVersions in canton.
Will be needed until https://github.com/DACH-NY/canton/pull/16992 goes through.
---------
Co-authored-by: Azure Pipelines Daml Build <support@digitalasset.com>
Co-authored-by: Paul Brauner <paul.brauner@digitalasset.com>
