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
This PR allows the script to run without GCP credentials. It will
obviously then skip the bits that require GCP credentials, but that
still leaves it with plenty of things to do.
Because checking all releases can still be quite long (around an hour on
CI, and my personal connection is a bit slower), this also introduces a
new parameter that restricts the number of releases to test.
CHANGELOG_BEGIN
CHANGELOG_END
* @daml/types: Improve Unit type
tl;dr: If we ever want to fix the `Query<T>` type from `@daml/ledger`,
we need a better definition of `Unit`.
TypeScript's type system may not be particularly sound, but the type
`{}` still sticks out as being a very special mess. I _think_ it is
something along the lines of
```typescript
type {} = Exclude<object, null> | string | number | boolean;
```
It is definitely not the type of all records or the type of only the
empty record.
I think it is reasonable to expect that the type relation defined by
```typescrupt
type Equiv<T, U> = T extends U ? U extends T ? true : false : false;
```
is extensional equality of types. Unfortunately, it isn't. For
instance, we have
```typescript
Equiv<{}, {[key: string]: string}> == true
```
but the value `{x: 1}` is assignable to type `{}` but not to type
`{[key: string]: string}`.
The type defined by the interface
```typescript
interface Unit {}
```
is a similarly hot mess as the type `{}`. Although they might seem to
be the same, particularly since we have
```typescript
Equiv<{}, Unit> == true and Equiv<Unit, {}> == true
```
here's a way to tell them apart:
```typescript
Equiv<Unit, {[key: string]: string}> == false
```
Thus, I would say the `Unit` type is mildly saner than the `{}` type.
Why does this matter? If we ever want to fix the query `Query<T>` type,
we need to be able to tell the unit type and `TextMap<_>` apart on the
type level. As demonstrated above, this seems impossible if we use `{}`
as the unit type but it is possible if we use the `Unit` type defined
above as the unit type.
Since I couldn't find a single value that is assignable to only one of
`{}` and `Unit` but not the other, this change should not break
anything at all. That said, I'll refrain from a changelog entry.
CHANGELOG_BEGIN
CHANGELOG_END
* Make eslint happy
CHANGELOG_BEGIN
CHANGELOG_END
* Spell out bazel directories in .gitignore
With the old `/bazel-*` pattern in there, `rg` also ignores files like
`bazel-haskell-deps.bzl`, which is quite inconvenient.
I obtained the list of what should be hidden by uncommenting the
`/bazel-*` line and adding evering `git status` showed as new files.
Thus, the list is hopefully complete.
We have a similar issue with `/compatibility/bazel-haskell-deps.bzl`.
Since I could figure out what exactly we want to ignore there, I just
added an un-ignore for that single file.
CHANGELOG_BEGIN
CHANGELOG_END
* Go with the unignore approach everywhere
CHANGELOG_BEGIN
CHANGELOG_END
This PR shuffles things around a bit to make it easier to test and
adds `--query-store-jdbc-config-env` which specifies the name of an
environment variable containing the jdbc URL. The UX for this is
modeled after #7660.
Added a test for the different formats.
fixes#7667
changelog_begin
- [JSON API] The JDBC url can now also be specified via
`--query-store-jdbc-config-env` which reads it from the given
environment variable.
changelog_end
@robin-da is taking care of 1.7.0-snapshot.20201013.5418.0.bda13392 (#7676), so they get pushed back to the end of the line.
Please do not merge this before #7676.
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Azure Pipelines DAML Build <support@digitalasset.com>
* allow updating user state from high-level trigger rule
* fix tests and examples for new rule signature
* fix doc for new rule signature
* add changelog
CHANGELOG_BEGIN
- [Triggers] ``rule`` can now ``get`` and ``put`` the user-defined state just
like ``updateState`` does. It no longer accepts the state as an argument.
You can port your rule function types by replacing ``s -> TriggerA`` with
``TriggerA s``, removing the last argument from the function, and using
``get`` to retrieve the state at the beginning of the ``rule``'s ``do`` block,
if needed.
See `issue #7674 <https://github.com/digital-asset/daml/pull/7674>`__.
CHANGELOG_END
* test that rule userState changes propagate all the way out
* adapt compatibility filtering to #7681
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
As part of multi-party read/write on command submissions we also need
to be able to support multi-party queries in DAML Script. Since the
queries in DAML Studio go via ParticipantView, this PR extends this as
a prerequisite to making use of this in DAML Script.
This does not yet relax any restrictions on command submissions. Those
still require a single committer.
For consistency with the surrounding code, I went for a simple Set
rather than a non-empty Set.
changelog_begin
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
* add ACS reader to TriggerA and TriggerStateA
* propagate changes in TriggerA, TriggerStateA structure
* allow query to be used in updateState and rule
* remove getTemplates
* remove ACS argument from updateState and rule
* fix type parameter order on query
* use query function in all tests and examples
* replace getContracts with query in documentation
* use wildcards instead of otherwise
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* rename TriggerStateA to TriggerUpdateA
- suggested by @cocreature; thanks
* missed renamings of TriggerStateA to TriggerUpdateA
- suggested by @cocreature; thanks
* make the meaning of the rlift functions clearer
* make initialize a TriggerInitializeA instead of a function; remove getContracts
* update tests and examples for new initialize signature
CHANGELOG_BEGIN
- [Triggers] Trigger ``updateState``, ``rule``, and ``initialize`` functions no
longer accept an ``ACS`` argument; instead, they must use the ``query`` action
to query the ACS, similar to the same function in DAML Script.
See `issue #7632 <https://github.com/digital-asset/daml/pull/7632>`__.
CHANGELOG_END
* disable older compatibility trigger builds
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* add silent_annotations option to da scala bazel functions
* use silent_annotations for several scala targets
* use silencer_plugin instead when the lib isn't used
* use silent_annotations for several more scala targets
* use silencer_lib for strange indirect requirement for running tests
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
* silent_annotations support for scaladoc
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
Currently the list of node that correspond to a "by key" operations
is tracked in the Transaction metadata. this PR move this information
into the nodes themself.
This is a preparatory work to include this information in the serialization
format for transactions
This advances the state of #7622
CHANGELOG_BEGIN
CHANGELOG_END
This PR fixes a bug in the PackageCommitter introduced recently.
Dependencies not decoded are assumed to be already preloaded and
should not bee looked for.
CHANGELOG_BEGIN
CHANGELOG_END
Somehow I didn’t realize that this section was actually important and
removed due to the sdk mention and because it seemed a bit
useless. This has now resulted in Maven rejecting our
packages. Apologies for the mess.
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>
The existing version of the migration replaced null values with
empty arrays. The presence of null values is used by the queries
to discriminate create and exercise events. This caused an
illegal state exception when reading active contracts for the API
(which are represented by their create events on the events table)
as the reader was mistakenly reading exercise events and create
events.
changelog_begin
changelog_end
