Haskell allows for promoting types to the kind level with the
`DataKinds` extension. Since DAML-LF has no similar concept (and
frankly speaking should't have one), this does not work well with
data-dependencies. Unfortunately, we need to enable the `DataKinds`
extension by default in `damlc` since our record system and the
`Numeric` type depend on it. Thus, issuing a warning that the
`DataKinds` is not supported with data-dependencies is not an option
and we need more refined warnings.
Most uses of promoted kinds won't even compile to DAML-LF and there's
no need to warn about those since they cause hard failures. However,
we need some limited support for type-level strings and the `Symbol`
kind, for type-level numbers and the `Nat` kind, as well as for some
stuff from `DA.Generics`. Type-level numbers and the `Nat` kind work
reasonable well since we have them in DAML-LF too. The `Symbol` kind,
and the types and kinds from `DA.Generics` are "erased" during
conversion to DAML-LF by replacing them with either a special `Erased`
type or the star kind. Thus, these entities are not restored properly
with data-dependencies. In combination with type classes this leads
easily to instances that for different types in the original code but
are at conflict during interface reconstruction. Long story short,
erased types/kinds and type classes don't work with data-dependencies.
We have a hack to somehow preserve type-level string since we need that
for our record system and the `HasField` type class. I have no desire
to support this hack for arbitrary type classes coming from the user.
Thus, I consider type-level strings to be erased as well here.
This PR adds a warning whenever a user is attempting to define a type
class that involves a kind that will be erased or an instance that
involves a type that will be erased. The warning tells the user that
this does not work with data-dependencies and is hence not upgradable.
There is one caveat: the `HasField` instances produced by the
propressor fall in the category we should warn about as well. Since not
supporting them would make our record system unusable, we need to give
them special treatment in data-dependencies. Thus, warning about them
would be unjustified noise and we explicitly exclude them in the code
producing the warnings.
CHANGELOG_BEGIN
[DAML Compiler] Issue warning when advanced types are with type classes
in a way that is supported by data-dependencies.
CHANGELOG_END
Stop emitting warnings about un-upgradability when our users use the
`InstanceSigs` or `MultiWayIf` extensions. These are safe.
Also don't issue warnings for `Cpp`, which can only be used internally.
CHANGELOG_BEGIN
[DAML Compiler] Add `InstanceSigs` and `MultiWayIf` to the list of
language extensions that don't cause problems with data-dependencies.
CHANGELOG_END
* Warn when importing DA.Generics
The module `DA.Generics` is hidden from the docs of `daml-stdlib`
because we consider it experimental. On top of that, the comments at the
top of the module make it clear that this module does _not_ work across
different SDK versions. Nevertheless, let's make it crystal clear that
`DA.Generics` does not work with data-dependencies and will stop you
from upgrading your package.
I've decided against using the a `{-# WARNING ... #-}` annotation
on the `DA.Generics` module declaration since that issues a warning for
every single time an enitity from the module is used rather than once
when importing the module. To me, that's a bit over the top since it is
conceivable that people still want to use the module during some stages
of their development. Another thing we might need to consider soon is a
`-fno-data-dependencies-warnings` flag which suppresses warning related
to data-dependencies. This would be impossible with a
`{-# WARNING ... #-}` annotation.
CHANGELOG_BEGIN
[DAML Stdlib] Issue a warning when importing the `DA.Generics` module,
which does not work with data-dependencies.
CHANGELOG_END
* Fix typo
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Unfortunately, diagnostics use 0-based ranges internally but render
them 1-based when showing them to users. This has caused a lot of
confusion in the `damlc` integration tests because we communicate
with our own devs in a mixture of the user facing 1-based format and
the 0-based internal format. On top of that, we had a bug where the
column numbers were off by 1.
Let's put this to an end and display all ranges in the 1-based format
meant for humans. To make sure our parser and renderers for ranges
are in sync, and not again off by 1, we also add a couple of tests to
check that they roundtrip.
CHANGELOG_BEGIN
CHANGELOG_END
The new version of `ghcide` fixes a bug in the pretty printer for
diagnostics. So far, the column number for an error/warning you would
be shown by `daml build` was always be one smaller than in DAML
Studio. Now, we show the same locations across the command line tools
and the IDE.
We also bring our test files in sync with the ranges the command line
tools print now.
CHANGELOG_BEGIN
[DAML Compiler] Show the correct column numbers in error locations
produced by command line tools like `daml build`.
CHANGELOG_END
* Warn on potentially un-upgradable language extensions
We issue a warning whenever a module is compiled with a language
extension enabled for which we are not certain that it works with
data-dependencies. Currently, we consider all extensions except for
the ones enables by default, `ApplicativeDo` and
`PartialTypeSignatures` problematic in this regard. The list of
extensions that work fine with data-dependencies might extend over
time but we need to do further research and add further tests before we
add any extensions.
The warning is always put at the location of the module name regardless
of where the `{-# LANGUAGE ... #-}` pragma is actually used. This is due
to the fact that the `ParsedModule` we get from GHC does not contain
the location information of these pragmas. We should probably improve
this over time but I think it is acceptable for now.
CHANGELOG_BEGIN
[DAML Compiler] Warn when a module uses a language extension that
might not work with data-dependencies.
CHANGELOG_END
* Make the warning less polite :)
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Bump the version of ghcide we use
The new version gives access to the `ParsedModule` instead of only the
`ParsedSource` in the preprocessor. See
https://github.com/digital-asset/daml-ghcide/pull/3
for details.
We also need to fix a few things in `bazel-haskell-deps.bzl` to reflect
that we use our fork of `ghcide`, which lives in
`digital-asset/daml-ghcide`, instead of the old
`digital-asset/ghcide`, which we handed ove to the community, now.
CHANGELOG_BEGIN
CHANGELOG_END
* Update to use fixed ghcide version
CHANGELOG_BEGIN
CHANGELOG_END
* Add functional dependency metadata in LF.
This PR adds a new value definition during LF conversion, for type classes with functional dependencies. The binding is a representation of the functional dependency, so we can later pick it up in data-dependencies.
For example, given a typeclass `Foo a b c` with the functional dependency `a -> b, c -> a b` will give rise to a new value definition `$fdFoo` (`$$fdFoo` after name mangling) of type:
```
forall (a : *) (b : *) (c : *).
{ _1: {_1: a} -> {_1: b}
, _2: {_1: c} -> {_1: a, _2: b}
}
```
where the `{ ... }` are LF structs. This is a simple encoding of the underlying representations for functional dependencies (which is `[([TyVar], [TyVar])]`).
The PR also adds a test to make sure the functional dependency metadata is exposed, and handles kinds other than kind star correctly. The use of this metadata in data-dependencies is left to a separate PR.
changelog_begin
changelog_end
* Add comment
This fixes a bug in the Speedy interpreter. With this change, the
interpreter crashes if it attempts to fetch using a contract key that
has an empty set of maintainers. This propagates to exerciseByKey as
this command is compiled using fetchByKey speedy built-in.
This is a breaking change approved by @bame-da .
CHANGELOG_BEGIN
[LF] (Bug fix) enforce non-empty maintainers in contract key during fetchByKey and exericiseByKey.
CHANGELOG_END
Small comment: This is technically not completely backwards compatible
since it messes with type inference. But to hit that you are doing
something sufficiently advanced that you should be able to add the
type annotation that is required
fixes#7635
changelog_begin
- [DAML Script] `query`, `queryContractId` and `queryContractKey` now
accepts multiple parties using the `IsParties` abstraction used by
`signatory`, `observer` and other fields. They will return all
contracts for which any of the given parties is a stakeholder. Since
`Party` is an instance of `IsParties`, this is fully backwards
compatible.
changelog_end
This PR adds a tests to check that the following DAML features,
possibly hidden behind language extensions, work with
`data-dependencies`:
* data constructor operators
* type operators
* partial type signatures
* ambiguous types
* instance signatures
* undecidable instances
CHANGELOG_BEGIN
CHANGELOG_END
We have plenty of tests that check that a certain feature can be used
with data-dependencies. Most of these tests have exactly the same
structure and have most likely been copied and pasted. Let's put an end
to this and use a function abstracting this test pattern instead. I'll
add quite a few more tests of this kind, so the gains will be even
bigger than shown here.
CHANGELOG_BEGIN
CHANGELOG_END
This PR adds default method support in data-dependencies,
including default method signatures (the DefaultSignatures
extension). This adds tests for simple default methods,
and for default methods with signatures.
changelog_begin
- [DAML Compiler] `data-dependencies` now support default
methods in typeclasses, including default method
type signatures.
changelog_end
* LF: enforce non-empty maintainer in contracts key lookup
This fixes a bug in the Speedy interpreter. With this change, the
interpreter crashes if it attempts to lookup using a contract key that
has an empty set of maintainers.
This is a breaking change approved by Bernhard Elsner.
CHANGELOG_BEGIN
- [LF] (Bug fix) enforce non-empty maintainers in contract key during
lookupByKey.
CHANGELOG_END
* Apply suggestions from code review
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Address Moritz's review.
* Address Martin's review
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* add ActionState to the standard library
* use 1 ActionState, 1 get, 1 put in low-level trigger library
* introduce TriggerStateA for updateState
* fix tests and examples for new updateState signature
CHANGELOG_BEGIN
- [Triggers] The ``updateState`` function now returns a ``TriggerStateA``. This
is an action like ``TriggerA``, but doesn't permit emitting commands. Instead
of taking the state as an argument and returning a new state, you can
manipulate the state with ``get``, ``put``, and ``modify``. Any existing
``updateState`` can be ported by replacing ``s -> expr`` in the lambda
expression with ``-> modify $ \s ->``, and then made to look nicer from there
as desired.
See `issue #7621 <https://github.com/digital-asset/daml/pull/7621>`__.
CHANGELOG_END
* some DAML docs for updateState and TriggerStateA
This fixes a bug in the Speedy interpreter. With this change, the
interpreter crashes if it attempts to create a contract containing a
contract key that has an empty set of maintainers.
This is a breaking change approved by Bernhard Elsner.
CHANGELOG_BEGIN
- [LF] (Bug fix) enforce non-empty maintainers in contract key during
contract creation.
CHANGELOG_END
* Fix qualified name handling in DAML REPL
This fixes the issue reported in
https://discuss.daml.com/t/how-to-use-qualified-template-names-in-repl-queries/1329/7
We need to print names qualified otherwise, the type signature for
following lines will be ambiguous even if users qualified the name in
their input. Figuring out the right name to use in qualification is
tricky but Luckily GHC provides this already so we just have to make
sure to plug it into the right places.
changelog_begin
- [DAML REPL] Fix a bug where you got an error about a name being
ambiguous even if you used a qualified name.
changelog_end
* Update compiler/damlc/daml-compiler/src/DA/Daml/Compiler/Repl.hs
Co-authored-by: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Factor out typechecking of imports
changelog_begin
changelog_end
Co-authored-by: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Write proper SDK version in DAR manifest for snapshots
Currently, we don't write the actual SDK version in the DAR manifest but
rather the version that has been sanitized for `ghc-pkg`. For proper
releases, these are identical but for snapshots the latter does not
contain the `-snapshot` part and the commit hash because `ghc-pkg` can
only handle numeric components.
This PR changes this behaviour such that we write the actual
unsanitized SDK version in the DAR manifest.
The implementation might look a bit unintuitive. However, we use the
`PackageSdkVersion` type for exactly two things:
1. Writing it into the manifest.
2. Using it to initialize the package database.
As mentioned above, the former should not be sanitized whereas the
latter should. So far, we've done the sanitization right after reading
the SDK version from `daml.yaml` or `DAML_SDK_VERSION`. Now, we do the
sanitization only in the code concerned with initializing the package
database.
CHANGELOG_BEGIN
[DAML Compiler]
- Bugfix: write the proper SDK version in the DAR manifest for
snapshot releases instead of a sanitized version
CHANGELOG_END
* Drop SdkVersion.toGhcPkgVersion entirely
CHANGELOG_BEGIN
CHANGELOG_END
* Fix data-deps dictionary function name mismatches.
Fixes#7362. Incredibly, it's possible to fix this issue in
data-dependencies by sorting instance names in a funny way.
This is definitely a hack, but it should fix this issue,
which affects overlapping instances as well.
This PR adds a regression test.
changelog_begin
changelog_end
* Fix comments
* apply suggestion
I originally implemented this for another change where I didn’t need it
in the end. However, it seems like a nice cleanup so spinning it out
into a standalone PR.
changelog_begin
changelog_end
To make `--import` work we also need to expose the
packages. Otherwise, we end up with a ton of confusing errors as soon
as you try anything. Luckily, we can do this fairly cheaply by using
the fact that GHC can expose both unit ids as well as just package
names. Until I realized that I started working on a different approach
of reading the DALFs first to resolve unversioned packages but that
seemed much more messy.
changelog_begin
changelog_end
* Added Functor instance for (,,) for completeness with fst3, curry3, etc
* added missing unit tests for DA.Tuple
* Reverted Functor instance on (,,)
* fix lint expectation line numbers
* Fix line numbers
changelog_begin
changelog_end
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Add new tests to demonstrate that authorizing checking is interleaved with execution. This work is a follow up to PR #7400, and relates to issue #132
changelog_begin
changelog_end
* naming and other small review comments
This command will be deprecated as part of the 1.6 release.
`daml build` should be used instead to build DARs.
CHANGELOG_BEGIN
[damlc]
- Deprecate `daml damlc package` command.
CHANGELOG_END
* Force newtype ctor name to match type name.
This PR fixes the record constructor check to include newtypes, which are represented as records in DAML-LF. The non-inclusion of all newtypes was an oversight. In addition, we add a regression test.
changelog_begin
- [DAML Compiler] bugfix: Newtype constructors must have the same
name as the newtype itself, since newtypes are record types.
changelog_end
* Change error message on newtypes
* update a test
* remove failedTransactions field from ScenarioLedger.RichTransaction
changelog_begin
changelog_end
* remove Blinding.checkAuthorizationAndBlind; fixup callers to use Blinding.blind when blindningInfo is required
* rename/relocate: ScenarioLedger.CommitError.FailedAuthorizations --> SError.DamlEFailedAuthorization
* fix types to demonstate that at most one FailedAuthorization is detected/reported
* address small review comments
* Speedy: group compiler parameters into a Config case class.
Speedy compiler is parametrized by several option flags. Those flags
are passed through different calls (in particular in the instance of
`CompiledPackages`.
This PR group all this configuration parameters into a case class to
pass the option in a cleaner way.
CHANGELOG_BEGIN
CHANGELOG_END
changelog_begin
changelog_end
Adapt test for small error message change. An improvement! Previously an internal message was shown. Make test flexible enough to pass for old & new message.
Adapt expected output file. Only change is the contract-ids for active-contracts when the test ends.
fix small test bugs in testcase where authorization is wrong
temp disabled 3 tests; needs investigation; see TODO markers
temp adapt 1 test for change in error message
temp disable 1 test. needs invesigation
undo accidentally commited change to .bazelrc
add copyright header to new file
remove testcase (badActorCheck2) which is no longer expected behaviour, when authorization occurs during execution
address comments: be mre private & other tiny changes
appease scala formatter
improve expected error message in KeyNotVisibleStakeholders testcase
fix authorization issues and re-enable the 3 failing tests in EngineTest which now pass
fix auth issue and re-enable ledger-test-tool test: WronglyTypedContractIdIT
fix compatibility
re-enable test in KVUtilsTransactionSpec.scala
* add 'alter' function to DA.Map
CHANGELOG_BEGIN
CHANGELOG_END
* swap arguments for alter
- suggested by @cocreature; thanks
* alter moved to stdlib, remove from trigger lib
* use markdown formatting for alter doc
- suggested by @sofiafaro-da; thanks
* fix code block formatting
- suggested by @sofiafaro-da; thanks
* add Ord (ContractId a) instance
* change inner list in activeContracts to map
* adapt Internal module to new map
* support rest of Trigger daml lib
* rename adjust to alter, its Data.Map name
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* distribute type arguments for ACS activeContracts
- suggested by @cocreature; thanks
* swap arguments for alter
- suggested by @cocreature; thanks
* reformat groupActiveContracts signature
- suggested by @cocreature; thanks
