* Full package name collision check
* Handle type synonyms appropriately
* Better comment
* Make isAscendant case-insensitive
* Document isAscendant and explain case-insensitivity
* Add a package-wide name collision test.
* Refactor packaging logic
This is a first step towards cleaning up the packaging logic and
adding some comments to make it clearer what is going on. There are no
functional changes in this PR.
There is more stuff here that we can and should cleanup but I will
leave that for separate PRs.
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Document topological sorting
* Undo requiredE change
Sadly, I haven’t managed to come up with an isolated test case for
this but I’ve tested this on a large internal codebase and it fixes an
issue with damlc build --incremental=yes.
* language: suffix all dalfs dependencies in a dar with the pkgid.
This makes sure that dalf dependencies are not accidentally overwritten
when two packages with equally named dalfs are imported.
* factor out parseUnitId
This is a first step towards making sure that the package ids for
types defined in daml-prim and daml-stdlib don’t change. This PR
mostly adds all the necessary infrastructure for that and moves
GHC.Types and GHC.Prim to make sure it works.
Until data-dependencies are really solid and we have verified that we
no longer have performance issues with an increasing number of Haskell
packages, we still include the source files in daml-prim and then just
rewrite the references.
We will also need to add tests that these packages really have stable
ids but I’ll leave that for separate PRs since this doesn’t make that
much sense anyway until all of the types have moved to stable
packages.
CHANGELOG_BEGIN
- [DAML Compiler] The modules GHC.Prim and GHC.Types from daml-prim
have been moved to separate packages.
CHANGELOG_END
* Track used packages during whole of engine submit
- Introduce MutableCompiledPackages interface
- Add TrackingCompiledPackages that tracks fetched packages
- Make used packages in transaction optional to distinguish between
missing dependencies and empty set of dependencies.
* Reimplement package dependency tracking
- Compute direct dependencies of a package during decoding
- Compute transitive dependencies of a package when adding a package
to engine.
- Annotate the resulting transaction with package dependencies
in Engine.submit.
* Create Ast.Package with proper direct deps in scenario service
While we don't have use for direct dependencies of a package in
scenario service (only Engine.submit needs it), it's better to be
accurate.
This of course overapproximates the direct dependencies.
* Compile a each new package once in ConcurrentCompiledPackages
I’ve gone through references to generic templates in our codebase to
see what else we can drop. In this case, we are still using
coerceContractId so I’ve updated the comment to explain the current
usecase.
We needed this for our generic template hacks. Since they are gone now,
I'm very much in favour of removing this extension since "undecidable"
always sounds a bit scary, even if it is only at compile time.
CHANGELOG_BEGIN
- [DAML Compiler] Don't make `UndecidableSuperClasses` a default language
extension for DAML anymore. If you really need this feature for a module,
you can reenable it using a `LANGUAGE` pragma at the top.
CHANGELOG_END
* Introduce a simpler template desugaring without support for generic templates
This adapts the LF conversion to the new template desugaring
introduced in our GHC fork. The guiding principle is that we use the
typeclasses directly to avoid generating, typechecking and converting
redundant code caused by indirections. I updated the template
desugaring documentation so that is probably a good starting point for
reviewing this.
* Address review comments
* Fix daml doc tests
* Fix data dependency tests
* Switch to new ghc-lib release
Display the actual number the user tried to use instead of 1.2345.
The logic to display the number is not perfect but definitely better than
we have now. If somebody knows a _simple_ way to do this better, please
tell me about it.
Until now, we broke long party names in the table view in the scenario at
spaces. This looked quite ugly.
Now, we don't break them at spaces. At the same time we also moved the CSS
into a file rather than having it in the code to make changes like this one
easier in the future.
This fixes#3642.
This reenables the migration checks. The migration command now only
generates stumbs for conversions instead of using the formerly (generic)
upgrade template.
* Successfully parse rss xml and find latest blog post object
* Show notification with link to blog (on every ide startup...)
* Only show blog post if not seen before
* Formatting
CHANGELOG_BEGIN
- [SDK] Notify IDE users about new daml-driven blog posts
CHANGELOG_END
* Add setting for user to opt out of notifications
* Use await rather than then
* Catch and swallow exceptions
* Another await and minor cleanup
We don't drop full support from the compiler yet but rather ban their use by
adding a check to the preprocessor. We'll remove the actual support as we go
along with fixing the upgrading story.
CHANGELOG_BEGIN
- [DAML Compiler] Make the experimental feature "generic templates"
unavailable. The current implementation is at odds with other, more important
language features still under development.
CHANGELOG_END
* daml-lf: rename Map to TextMap in archive proto
+ in Scala/haskell AST
* a bit more renamming
* Update compiler/daml-lf-tools/src/DA/Daml/LF/TypeChecker/Serializability.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* fix test
* Apply suggestions from code review
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Update compiler/daml-lf-ast/src/DA/Daml/LF/Ast/Base.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Set Sdk-Version in DAR Manifest to compiler SDK version.
CHANGELOG_BEGIN
- [DAML Compiler] Bugfix: The Sdk-Version field in a DAR manifest file
now matches the SDK version of the compiler, not the sdk-version field
from daml.yaml. These are usually the same, but they could be different
if you set the DAML_SDK_VERSION environment variable before running
``daml init`` or ``daml build``.
CHANGELOG_END
* Fallback to daml.yaml if env var not set
* add yaml dependency
* Always require sdk-version, and emit warning on mismatch with env var
* More explicit about where override comes from
* Add packaging regression test
* generate choice instances for cross sdk dependencies
* add line to test cross-sdk exercise of choice
* revert to naming choice in GenerateSimpleDalf as "NotChoice"
* remove filter/special-handlimg for "Archive" choice
* dont assume a tycon with the same name as a choice; instead use type from chcArgBinder
* error if cant find the template datatype def
* naming
* avoid intercalate followed by re-split on "." in module name
* GenerateSimpleDalf: have two choices: one of record type, one of variant type
* Update Upgrade.hs
* added some linebreaks, spaces for readability
* address cosmetic comments
* use Sdk. prefix as necessary so tests work
* mollify hlint
* fix: daml-assistant/integration-tests
* Change title of release notes tab
This suggests that a new release is available, but not necessarily
installed. We do this for the case that the extension is updated
(which triggers the tab to open) but the actual SDK is not.
* Keep 'New'
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
* MVP for a daml2ts codegen
This PR adds an MVP for a codegen for TypeScript.
Given a DAR, daml2ts replicates the structure of the serializable type
definitions in it as TypeScript type definitions following our JSON
representation of DAML-LF types. It also adds decoders for all these types,
which can be used to check where an arbitray JSON value has the given type.
Finally, daml2ts also produces one JavaScript object for each template, which
reflects the type information of that template.
All produces objects implement some interfaces defined in a TypeScript
library currently called `@digitalasset/daml-json-types`. This libary is not
yet uploaded to NPM but rather included in the `tests/ts/daml-json-types`
directory. This libary also contains the JSON decoders for all of DAML-LF's
builtin types.
There are quite a few limitations right now. Most notably, variant and enum
types are not properly typed right now but rather gradually "typed" as
`unknown`. We also don't support nested `Optional`s, the `Numeric` type or
sum-of-product types in DAML. These issues are tracked in #3518.
There is currently one test. It takes a very simple DAML model, generates
the TypeScript for it and checks that it compiles and contains no linter
warnings/errors. Proper integration tests against the JSON API will follow.
* Address @cocreature's comments
* Make test work on Windows
* language: make only needed packages visible for cross sdk imports
This gives us more control over what packages are visible in the package
database during cross sdk imports and makes sure we're not accidentally
picking up the wrong one.
* Update compiler/damlc/lib/DA/Cli/Damlc/Packaging.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* deal with evil dalf imports
* Move packaging tests to a separate test suite
Originally, we had these as part of the integration test suite since
`bazel run damlc build` couldn’t locate `ghc-pkg` but that has been
fixed for a while.
Moving it to a separate test suite speeds things up as the integration
tests are rerun very often and also makes development much more
convenient since the new test suite supports `-p` properly to filter
to specific tests.
For now, I’ve left the upgrading tests as part of the integration
tests. I expect that we probably want to factor those out to another
test suite as well.
* fix warnings
Previously we opened file FooX before FooX+1 which we import from FooX
so there is a race condition if we try to resolve imports in FooX fast
enough. Now we open them in reverse order to fix this.
The other option would be to write all files to disk before opening
them but given that we can easily avoid this here, I’d rather keep
things in memory.
It has grown large enough that by now it definitely deserves to be in
its own module.
This PR does not change any of the actual code, it simply moves it around.
* language: fix for tuple types in source generation
We correct the source generation from dalfs containing TupleN data
types. A test is added to the integration tests of daml assistant and
the `generate-src` command is improved to make this test possible.
* check that tuple type comes from DA.Types
* check that compilation succeeded
* pattern match golf
* check for tuples between 2 and 20
This change allows to only import `module A` from the instances package
if data dependencies are present instead of `module A` and `module
AInstances`.
* Add toAnyContractKey and fromAnyContractKey
This is necessary to add exerciseByKey to DAML triggers.
* Switch to proper ghc-lib release
* Remove unnecessary filter
* Bump timeout because macos is terrible
* bazel fmt
I didn't really read the code around the FIXME. After spending a few moments
on it, I'm now convinces the current behaviour is the right behaviour. I
can't think of a short way to explain it in a comment without inflicting my
my previous confusion on others. Thus, I just remove the FIXME.
* No longer depend on "@bazel_tools//tools/jdk:jar"
To avoid the following warnings
```
WARNING: /home/aj/.cache/bazel/_bazel_aj/c1e06e2358666d118d0ae50e2d32c25d/external/bazel_tools/tools/jdk/BUILD:124:1: in alias rule @bazel_tools//tools/jdk🫙 target '@bazel_tools//tools/jdk:jar' depends on deprecated target '@local_jdk//:jar': Don't depend on targets in the JDK workspace; use @bazel_tools//tools/jdk:current_java_runtime instead (see https://github.com/bazelbuild/bazel/issues/5594)
```
* Targets and files should not share names
To avoid the warning
```
WARNING: /home/aj/tweag.io/da/da-master/compiler/damlc/tests/BUILD.bazel:316:1: target 'simple-dalf.dalf' is both a rule and a file; please choose another name for the rule
```
* bazel: 0.28.1 --> 1.1.0
* bazel-watcher sha256
* Fix missing line in patch
* proto_source_root --> strip_import_prefix
See https://github.com/bazelbuild/bazel/issues/7153 for details.
* Update rules_nixpkgs
Required to avoid errors of the form
```
ERROR: An error occurred during the fetch of repository 'node_nix':
parameter 'sep' may not be specified by name, for call to method split(sep, maxsplit = None) of 'string'
```
and
```
ERROR: An error occurred during the fetch of repository 'node_nix':
Traceback (most recent call last):
File "/private/var/tmp/_bazel_runner/17d2b3954f1c6dcf5414d5453467df9a/external/io_tweag_rules_nixpkgs/nixpkgs/nixpkgs.bzl", line 149
_execute_or_fail(repository_ctx, <3 more arguments>)
File "/private/var/tmp/_bazel_runner/17d2b3954f1c6dcf5414d5453467df9a/external/io_tweag_rules_nixpkgs/nixpkgs/nixpkgs.bzl", line 318, in _execute_or_fail
fail(<1 more arguments>)
Cannot build Nix attribute 'nodejs'.
Command: [/Users/runner/.nix-profile/bin/nix-build, /private/var/tmp/_bazel_runner/17d2b3954f1c6dcf5414d5453467df9a/external/node_nix/nix/bazel.nix, "-A", "nodejs", "--out-link", "bazel-support/nix-out-link", "-I", "nixpkgs=/private/var/tmp/_bazel_runner/17d2b3954f1c6dcf5414d5453467df9a/external/nixpkgs/nixpkgs"]
Return code: 1
Error output:
src/main/tools/process-tools.cc:173: "setitimer": Invalid argument
```
* Update rules_scala
* .proto has been removed, use [ProtoInfo] instead
See
https://docs.bazel.build/versions/1.1.0/be/protocol-buffer.html#proto_library
* python3_nix add nix_file attribute
To avoid the following error
```
ERROR: /home/aj/tweag.io/da/da-bazel-1.1/BUILD:66:1: //:nix_python3_runtime depends on @python3_nix//:bin/python in repository @python3_nix which failed to fetch. no such package '@python3_nix//': Traceback (most recent call last):
File "/home/aj/.cache/bazel/_bazel_aj/5f825ad28f8e070f999ba37395e46ee5/external/io_tweag_rules_nixpkgs/nixpkgs/nixpkgs.bzl", line 149
_execute_or_fail(repository_ctx, <3 more arguments>)
File "/home/aj/.cache/bazel/_bazel_aj/5f825ad28f8e070f999ba37395e46ee5/external/io_tweag_rules_nixpkgs/nixpkgs/nixpkgs.bzl", line 318, in _execute_or_fail
fail(<1 more arguments>)
Cannot build Nix attribute 'python3'.
Command: [/home/aj/.nix-profile/bin/nix-build, "-E", "import <nixpkgs> { config = {}; overlays = []; }", "-A", "python3", "--out-link", "bazel-support/nix-out-link", "-I", "nixpkgs=/home/aj/.cache/bazel/_bazel_aj/5f825ad28f8e070f999ba37395e46ee5/external/nixpkgs/nixpkgs"]
Return code: 1
Error output:
error: anonymous function at /home/aj/.cache/bazel/_bazel_aj/5f825ad28f8e070f999ba37395e46ee5/external/nixpkgs/nixpkgs.nix:3:1 called with unexpected argument 'config', at (string):1:1
```
* rules_haskell unnamed string.split(_, maxsplit = _)
The keyword argument may no longer be named.
* string.replace(_, _, maxsplit = _) may not be named
* Move proto sources from deps to data
Fixes
```
ERROR: /home/aj/tweag.io/da/da-bazel-1.1/daml-lf/archive/BUILD.bazel:150:1: in deps attribute of scala_test rule //daml-lf/archive:daml_lf_archive_reader_tests_test_suite_src_test_scala_com_digitalasset_daml_lf_archive_DecodeV1Spec.scala: '//daml-lf/archive:daml_lf_1.6_archive_proto_srcs' does not have mandatory providers: 'JavaInfo'. Since this rule was created by the macro 'da_scala_test_suite', the error might have been caused by the macro implementation
```
* Define sha256 for haskell_ghc__paths
Bazel 1.1.0 fails on missing hashes.
* Disable --incompatible_windows_native_test_wrapper
* //compiler/daml-extension don't modify sources
Modifying sources in-place can cause issues on Windows, where build
actions are not sandboxed and changes on sources can affect other build
steps.
* bazel-genfiles --> bazel-bin
The bazel-genfiles symlink has been removed since Bazel 1.0.
See https://github.com/bazelbuild/bazel/issues/8651
* Mark dev_env_tool repository rule as configure
See
https://docs.bazel.build/versions/1.1.0/skylark/lib/globals.html#repository_rule
* Move data deps into data attribute
* Mark dev_env_tool as local = True
* Manually fetch @makensis_dev_env
When buidling simple project that has our favourite large project as a
dependency, this decreased
- total allocations from 63GB to 57GB
- run time from 34.0s to 31.5s
* language: introduce data-imports
Right now the user experience for importing dalfs and dars from
different sdks is quiet confusing. This PR tries to solve this. We add
an additional field `data-imports` to daml.yaml. These imports can come
from different SDK's and we will generate interface files containing the
data types and their Template instances.
This also simplifies the migration command, as it now always imports the
respective packages as `data-imports`.
Given that I initialy messed this up during development (that’s where
the `reverse` in setting up the typecheck env comes from), it seems
like a good idea to have a test for this :)
* Add support for on-disk incremental builds in damlc build
* Normalise file paths of internal modules because Windows
* stop stealing my $s hlint
* Apparently jars are also called exe
* Address review comments
* Bump to proper ghcide revision
* Display release notes using webview
* Use const and fix string
* Check for version upgrade before showing release notes
* Changelog entry
* Use node-fetch instead of web-request
* Remove spurious state update
* language: cross sdk dalf/dar imports
The final piece for cross sdk imports. With this PR we can import the
data types of packages and dalfs that were created with different sdks.
This is done by generating interface files from dalfs and an 'instances'
package that contains the template instance definitions of template data
types. The instances itself are defined via the `external` keyword,
which is inlined to proper daml-lf instance definitions given in the
respective dalf package.
We test that cross sdk imports work by importing the `simple-dalf` in
the daml-assistant integation tests and running a scenario.
* Allow data A = A by prepending DamlEnum$ to type name.
* Single con enums basically work.
* Fix export lists for single constructor enum types.
* Revert "Fix export lists for single constructor enum types."
This reverts commit 7475a3dfbe3531d3ef62fdbcfe64c01a9e22d7af.
* Switch to a "stupid theta" approach
* Clean up enum type preprocessor
* Run enum preprocessor on generated code.
* Add daml-docs golden test for single constructor enums
* s/genPreprocessor/generatedPreprocessor/g
* Update copyright header
* Update release notes
* Remove unnecessary OverloadedStrings
Currently we hide modules, for which we don't define an alias, when we
specify one alias for *one* module. With this change, all modules
without aliases are still exposed.
* language: refactoring of iface file generation and package db setup.
This is a refactoring of the damlc part that creates the package
database and the code generation for interface files. This is a
preparation for the cross sdk imports.
We also add an internal command to damlc to generate generic instances
code and use simple copying via {..} in the migration command. An
additional test checks that migration via generics still works.
* Update compiler/damlc/daml-compiler/src/DA/Daml/Compiler/Upgrade.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* clearer description for generate-gen-src
* updated documentation
* correct copy/pasta mistake
* added a comment on different build options in migration command.
* Update compiler/damlc/lib/DA/Cli/Damlc.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* resolve dalf paths from dar manifest
* added a comment on different headers in upgrade modules.
* removed monoid instance for ExtractedDar
For numeric, the superclass dicts can be of the for `dict @10` so only
handling variables doesn’t work. Now we walk down applications and
check the name on the left.
