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
* Authorize trigger service on middleware
changelog_begin
changelog_end
* Trigger service auth callback handler
* Forward token
* Do not pin the application ID in the access token
The trigger service will assign an individual application ID to each
trigger based on its UUID. Requiring tokens on the granularity of
application IDs would break the idea of storing the token in a cookie to
be able to use it across multiple requests.
changelog_begin
changelog_end
* todo persist trigger token
* Add a state parameter to middleware login
* add documentation comments
* typo
* fmt
* Align Party type between middleware and trigger service
The middleware was using `com.daml.lf.data.Ref.Party` while the trigger
service is using `com.daml.ledger.api.refinements.ApiTypes.Party` which
requires conversions. This aligns the types to avoid such conversions.
* optional application id in oauth2 test server
* align party types
* configure auth middleware in trigger service tests
* handle empty cookie header
* follow redirects in trigger service tests
* keep track of cookies
* keep track of cookies
* Replace any previous Cookie header
Otherwise on old daml-ledger-token cookie might persist and be preferred
over a newly added instance.
* DEBUG
* Configure test ledger client readAs claims
* fmt
* docstrings
* remove debug output
* Avoid endless redirect loops
When the replay still fails to authorize on the middleware then we do
not want to attempt another login flow.
* Store callback routes in authCallbacks
* fmt
* Push AuthTestConfig into test target
https://github.com/digital-asset/daml/pull/7654#discussion_r506510193
* Unbind oauth2 server after middleware
https://github.com/digital-asset/daml/pull/7654/files#r506513251
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
daml-sdk-head: add optional sha information
This PR add an option, `--sha`, to `daml-sdk-head` so that it produces a
more accurate version number including the current git sha.
The main consequence is that calling `daml-sdk-head --sha` take
significantly longer than calling `daml-sdk-head`, because it needs to
recompile everything that depends on the version number.
> ## Wait, but why??
I started this work in support of an internal project that needed to
test against unreleased, and possibly unmerged, daml versions. However,
after further discussion I believe there is a better option for their
use-case. I've decided to still open this PR because the work was done
and there is no downside to it. It may still be useful if one wanted to
be able to maintain more than one non-released local version of daml.
CHANGELOG_BEGIN
CHANGELOG_END
* set doobie version to 0.9.2 and rerun maven pin
* port extractor and some of JSON API
* repin maven
* use doobie's own builder compatibility where required
* use probably bad derivations to supply Blockers where transactEC was required
- The point of using Blocker instead of ExecutionContext seems to be to
especially emphasize to API users that it isn't appropriate to use an
ExecutionContext with ordinary behavior. That is what we have done, which
should probably change, but just compiling for now.
* fix fragment inspection test for internal restructuring
- This test depends on implementation details of Doobie, so naturally it must be
altered when that runs. Fortunately, it's been made easier by the changes
in this upgrade.
* allow 256 blockers for navigator transaction blocker, like the global EC
* allow as many blockers as the pool size for trigger service
- The transactor shouldn't share ExecutionContext for transactions with the
caller, so we set up a new one based on configured pool size.
* no changelog
CHANGELOG_BEGIN
CHANGELOG_END
Removed ad hoc usages of UUID in ledger-api-test-tool for id generation for commands and keys.
This change should facilitate debugging.
CHANGELOG_BEGIN
CHANGELOG_END
There are two reasons for this:
1. 2018 was a long time ago and there seems to be no particular reason
for sticking to that version.
2. We have seen a bunch of issues where we get 404s when fetching msys
packages. The newer version has a larger mirrorlist which might help
with this. We could in principle try to patch the mirrorlist for
the old version but given that upgrading seems like a good idea
anyway, this seems easier.
changelog_begin
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
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