* Use a safer safeToReexport
This is much safer than the approximation from last time. The only downside is
introducing a dependency between data dependencies and our type checker,
but that seems safer than having two versions of `expandTypeSynonyms`
floating around (and perhaps this dependency is something we would end
up adding anyway).
changelog_begin
changelog_end
* Add own package to extPackages.
* Use mkTForalls
* simplify mkTForalls
* Re-export typeclasses in data-dependencies...
... whenever possible.
The `safeToReexport` over-approximation is simple but troubling, so
I'd like to get it fixed soon.
The inputs to generateSrcFromLfPkg (and the genInstances one) were
getting quite hairy, so I decided to pass a record instead.
changelog_begin
changelog_end
* Add a test
* Move generateSrcPkgFromLf to its original place
* Better docs and make envQualify more clear
* compute dependency ids in generate-src command
The packaging tests are already one of our slowest test suites and
damlc test takes quite a while since it has to spin up the scenario
service.
We already have tests for damlc tests so this PR moves the tests from
the packaging test suite that are specific to `damlc test` to those
tests which should balance things a bit better.
changelog_begin
changelog_end
Based on a comment by @cocreature in the last PR, this PR changes the
generation of typeclass instances to empty stubs, instead of adding
stub methods as well.
changelog_begin
changelog_end
Sadly my fix in https://github.com/digital-asset/daml/pull/4325 didn’t
seem to work (despite fixing the issue in my tests) so let’s mark this
as flaky until we figure it out.
changelog_begin
changelog_end
We have seen a couple of flaky tests runs on CI in the packaging test
caused by this. It is easy to reproduce if you add a delay in
diagnosticsLogger before printing the diagnostics which makes this
failure reproducible. With this patch, the diagnostics are always
printed even with a delay.
changelog_begin
changelog_end
* Remove mkOptions and defaultOptionsIO
`mkOptions` is a terrible API and this PR burns it with lots of 🔥.
The only thing that I didn’t simply move around is the validation
logic in `mkOptions` which validates that some directories
exist. Given that I’ve never actually see this be useful and the
options to set these directories (package dbs, import paths) are
internal I don’t think we actually gain anything from this.
I’ve also killed defaultOptionsIO which was a very confusing wrapper
around `mkOptions` that in addition to calling `mkOptions` also
enabled DLint. This was only used in tests, so I’ve enabled DLint in
the tests that need this.
changelog_begin
changelog_end
* newtype version header
* Generate mod refs at the same time as conversion
* Small change
changelog_begin
changelog_end
* lint
* Get rid of secondM
* Switch to Writer.CPS
* doc typo
* Added a partition function to prelude.
* Fixed partition function documentation.
* CHANGELOG_BEGIN
- Added `partition` function to prelude.
CHANGELOG_END
* Fixed partition documentation.
`initPackageDb` assumes that `Options` has not yet been initialized
and calls `mkOptions` itself. Each call to `mkOptions` appends the LF
version to the package db dir which means that calling it twice as we
did in `execIde` results in pkg dbs of the form dir/1.7/1.7 which is
obviously not what we want.
This is just the fix, I’m sufficiently annoyed by this now, that I’ll
spend some time tomorrow to kill mkOptions completely but for now this
at least fixes the SDK on master.
The reason why we didn’t catch this in our tests is that the package
dbs are located slightly differently via Bazel runfiles as they are
located in the final release tarball which ended up not breaking this
in our LSP tests.
changelog_begin
changelog_end
* Refactor modrefs out as a type.
This is in preparation for moving to a monadic style.
changelog_begin
changelog_end
* Update compiler/damlc/daml-compiler/src/DA/Daml/Compiler/DataDependencies.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Currently, the DAML language server use for DAML Studio crashes when the
`build-options` section of `daml.yaml` contains flags like `--package`.
This PR fixes this issue by allowing most of the flags for `damlc build`
for `damlc ide` as well.
CHANGELOG_BEGIN
- [DAML Studio] Allow all command line flags for ``daml build`` for
DAML Studio as well.
CHANGELOG_END
* Bazel test for trigger scenario
* daml-triggers: Allow testing trigger rules in scenarios
CHANGELOG_BEGIN
- [DAML Triggers - Experimental] DAML triggers can now be tested in
scenarios. Specifically, a trigger's ``rule`` can be executed in a
scenario and assertions performed on the emitted commands.
CHANGELOG_END
* Allow assertions on create commands
CHANGELOG_BEGIN
* [DAML stdlib] Add `CanAbort` instance for `Either Text`.
CHANGELOG_END
* Add convenience to construct ACS for testRule
* Add assertions for exercise and exerciseByKey
* fix assert message
* Test assertExercise(ByKey)Cmd
* unpackCommands --> flattenCommands
* Add API documentation
* Document that command ids start from "0"
* generalise command assertions to CanAbortm
* export ACSBuilder type
* Better haddocs for trigger command assertions
* explicit let
* ./fmt.sh
* Fix runfiles on Windows
* Add reference to Bazel issue
Co-authored-by: Andreas Herrmann <andreash87@gmx.ch>
fixes#3436
changelog_begin
- [DAML Compiler] ``damlc test`` now initializes the packagedb automatically which
means that it will work on projects that declare custom
``dependencies`` in ``daml.yaml`` without having to call ``damlc
init`` first.
changelog_end
* Preserve class method names during LF conversion.
This PR changes the LF conversion to pick names for dictionary
fields that will be easier to reconstruct as typeclasses
later.
For superclasses this uses "s_1", "s_2", "s_3" and so on,
and for methods this uses "m_foo", "m_bar", "m_baz" and
so on. (Is this enough C++?)
In the future we might want to distinguish between methods
that are mandatory and methods that are optional ... but
I think this should be good enough for now.
This PR also adds a test.
Fixes#4216
changelog_begin
changelog_end
* lint
* Run test in LF 1.7 as well
* Add test for superclass field.
They have been migrated to `ghcide` in
https://github.com/digital-asset/ghcide/pull/388 which is a much more
sensible place for them to live given that the code is in that repo.
changelog_begin
changelog_end
* Fail when a data-dependency fails to compile
Previously, we emitted errors but just kept on going which sometimes
kinda works but is certainly not the right thing to do.
Now we just crash and abort compilation.
changelog_begin
changelog_end
* why is windows
* undo crap
This fixes#4114 and cleans up the situation around
`data-dependencies` and `dependencies` as described in #4218.
There is still more work to be done here mostly around ironing out all
the edge cases and producing useful error messages instead of
silentely doing the wrong thing but I’ll leave that to a separate PR.
To test this, I’ve fixed the packaging tests to no longer deduplicate
package ids (which means they would return the wrong number if
daml-prim ends up in there twice) and I addded a test where we have 3
projects:
- `lib`
- `a` which depends on `lib`
- `b` which depends on `lib` via `dependencies` and 'a' via
`data-dependencies`.
changelog_begin
changelog_end
* Converting functions in data dependencies.
changelog_begin
changelog_end
* Add NoOverloadedStrings to the set of extensions in generated packages.
* Just use the fn as its own right hand side
* Restore order of package map (not that it makes a difference)
* Adjust imports
* Weird lint but ok
* Make the test pass somehow
* Dont preprocess enums in GHC.Prim
* Preprocess enums everywhere, and add mod ref as needed.
* Revert preprocessor changes
* Dont expose old-style typeclasses
* Dont convert newstyle typeclasses temporarily either
* Add test for function importing
* Support DAML-LF type synonyms in scala.
CHANGELOG_BEGIN
CHANGELOG_END
* dont create synonymns in GenerateSimpleDalf
* extend DAML-LF parser to support type synonyms
* test: expand type synonyms correctly
changelog_begin
- [DAML Compiler] Choices marked explicitly as `preconsuming` are now equivalent to a non-consuming choice that calles `archive self` at the beginning.
changelog_end
Co-authored-by: Shayne Fletcher <shayne.fletcher@digitalasset.com>
* Remove damlc.jar
We never advertised or published this externally and our only internal
user has moved off this months ago already.
changelog_begin
changelog_end
* Remove dependency from navigator test lib on damlc jar
* Handle unserializable scenario result types
Previously, the conversions made some attempt at guarding against this
by matching on SPap and PClosure. While it would be possible to extend
this to match on STypeRep, this doesn’t actually fix the issue since
this can be nested, e.g., you can have a record with a field that is
an SPAP.
This PR changes this to simply catch any errors thrown from
`toValue`. While this feels a bit ugly, I think it’s a reasonable fix
for now.
changelog_begin
- [DAML Studio] Scenarios with unserializable result types no longer
crash the scenario service.
changelog_end
* Only run test on DAML-LF >= 1.7
* Remove intermediate PackageImport type
We can just reuse GHC’s PackageFlag directly which simplifies things a
bit.
changelog_begin
changelog_end
* windows is bad
* meh
* foobar
* why
To differentiate between "data X = X" which is translated to a DAML-LF
enum and "data X = X {}" which is translated to a DAML-LF record, we
add a datatype context with GHC.Types.DamlEnum. For
`data-dependencies` this needs to point to Currentsdk.GHC.Types.
changelog_begin
changelog_end
* Use GHC’s syntax for the --package flag
The previous syntax was just based on the Read instance of a 3-tuple
which was pretty much unusable. This changes it to GHC’s much nicer
syntax.
I deliberately did not add a changelog entry for this, since this
flag isn’t something that we have documented at all and it is
currently only useful in combination with data-dependencies.
fixes#4126
changelog_begin
changelog_end
* Fix hlint
* get it to compile 😇
* shut up hlint
* Remove the key field from pkg.conf files
We never use this and it only a legacy field that is deprecated in
favor of id in GHC.
There is also a minor change in the docs around ExposePackage which
should at most affect error messages.
changelog_begin
changelog_end
* Better error messages
The packaging tests have grown a fair bit recently and seem to hit
timeouts sometimes. We might want to split it up into multiple tests
suites but for now this should help.
changelog_begin
changelog_end
The current code has gotten out of sync with the changes to template
desugaring and is therefore simply broken. In addition to that, we
don’t need this once we can use typeclass instances in combination
with data dependencies.
Initially, we just disabled this instead of removing it since we
thought it might still be useful for older packages before typeclasses
are desugared to type synonyms. But we already have one way of
handling those as evidenced in the tests for the DAVL and once we can
call functions from older packages (which works regardless of whether
they have been built before or after the changes to how typeclasses
are desugared), we have another one so I don’t think it makes any
sense to keep this code around.
changelog_begin
changelog_end
* Refactor damldocs
* Refactor damldocs.
changelog_begin
changelog_end
* More refactoring
* Update copyright headers.
* Add export list for Templates
* Add export list to .Util
* added a little ^
* Test data-dependencies for more LF version combinations
This PR extends the cross-LF version tests to run for all
combinations where depLfVer >= targetLfVer.
changelog_begin
changelog_end
* Fix comments and add TODO
This PR fixes a minor issue where we were including more references
than we need which causes problems on older SDKs where GHC.Prim is not
a stable module since GHC.Prim cannot be imported (it’s builtin GHC
magic).
More importantly, this PR adds a test for cross-SDK data-dependencies
against the DAVL DAR which is built with SDK 0.13.32 before we started
making all the changes. The test also includes a slightly hacky but
mostly reasonable way of actually using the templates instead of just
the data types from the DAVL DAR which and a scenario to test this.
changelog_begin
changelog_end
This fixes the ZIP modification times in all DARs to a specific
value (1980-01-01) whereas they used the current time before. This
both gives us the nice property that not only our DALF builds but also
DAR builds should be deterministic (and there is a test for this). I
have a suspicion that this could help significantly with build times
and avoid rerunning half of the Scala tests on a change to damlc that
should not change the DALFs.
changelog_begin
- [DAML Compiler] The modification times in a DAR are now fixed to a
given value which makes the output of ``daml build`` deterministic
in single-threaded mode (which is the default).
changelog_end
This PR fixes a whole bunch of bugs when using data-dependencies on a
package produced by damlc rather than the handcrafted simple-dalf.
The end result is that we are able to build a package with
`--target=1.6` and use it as a data-dependency from a package with
`-target=1.7`. While the test that I’ve added for this is not
cross-SDK it is arguably even trickier since we cannot rely on the
unit id of daml-stdlib changing the version in the unit id.
The changes all fall into one of the following two categories:
- Special handling for daml-prim and daml-stdlib to avoid collisions
with the one from the current SDK.
- Special treatment of stable packages to avoid generating new code
for those.
- Remove a couple of filters for daml-prim since we do need to include
daml-prim from a data-dependency if it is a different version.
This is definitely not perfect and there are a bunch of rather hacky
parts in here but it seems like a good intermediate step (and it has a
test :))
changelog_begin
changelog_end
This was accidentally set to 1.7 before for no reason. Note that this
simply meant that we did not use the stable module when compiling with
--target=1.6 since we filter out newer stable packages.
Nevertheless, I’ve also added a test that verifies that we do not
accidentally introduce dependencies on packages in newer LF versions.
changelog_begin
changelog_end
* Try to improve the docs on DA.Internal.Template.Functions a little.
* More docs.
changelog_begin
- [DAML Standard Library] The ``Template``, ``Choice``, and
``TemplateKey`` typeclasses have been split up into many small typeclasses
to improve forward compatibility of DAML models. ``Template``,
``Choice`` and ``TemplateKey`` constraints can still be used as before.
changelog_end
* Example typo
* Patterns and test for new desugaring
* working on new template conversion
* Update ghc-lib
changelog_begin
changelog_end
* shut up hlint
* Update desugar stdlib
* update test
* remove unuseful templatebinds
* Add implicit qualified GHC.Types import
* Add missing primitives
* Remove chaff
* update comments
* Remove patterns that dont seem useful anymore
* Capture key data in template binds
* Dont make TypeRep/ToAny/FromAny classes conditional
* Remove some unnecessary TODOs
* Generate the template definition
* Remove new template desugaring test
* Fix jq query
* Rename makeDesugarDFunProjection to useSingleMethodDict
* Let TTypeRep and TAny be TUnit in primitives.
* Fix damlc visual wrt the new desugaring
* Fix visualization tests in shake test suite
* Fix damldocs
* Drop envTemplateKeyData
* Use the new ghc-lib release
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Allow invoking generate-src on the main dalf of a dar
Given that daml build outputs a .dar file this is much more convenient
for testing against actual build outputs of damlc rather than
handcrafted .dalf files.
The behavior matches the one of `damlc inspect` in that it detects
whether it works on a .dar or a .dalf based on the file ending.
changelog_begin
changelog_end
* Update compiler/damlc/lib/DA/Cli/Damlc.hs
Co-Authored-By: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
