* update ghc-lib patch
* update stack-snapshot.yaml
changelog_begin
changelog_end
* bazel run @stackage-unpinned//:pin (on linux) and update stackage_snapshot.json
* testcase to check type signatures in template-lets are not ignored
* update to ghc-lib commit hash following merge
* update snapshot
* update snapshot after pin on windows
* update stack pin on linux
Co-authored-by: Nick Chapman <nchapman@digitalasset.com>
* Add DAML_EXCEPTIONS feature.
Part of #8020. This extracts the DAML_EXCEPTIONS feature from #8023
since we need it for typechecking & LF conversion soon.
changelog_begin
changelog_end
* add full url
* add another url
* Add exceptions in DAML-LF AST (Haskell side)
Updates the Haskell DAML-LF AST for exceptions, including
encode/decode, and updates all the functions that deal with the
AST directly.
changelog_begin
changelog_end
* Missed some TODOs in DecodeV1
* kvutils: Use ScalaPB to generate a Scala JAR for daml_kvutils.proto.
* Bazel: Delete the unused `da_java_binary` rule, and inline `_wrap_rule`.
* Bazel: Factor out Java/Scala protobuf class generation into a helper.
CHANGELOG_BEGIN
CHANGELOG_END
* daml-lf/archive: Use `proto_jars`.
* Bazel: Remove the visibility modifier from `proto_jars`.
It's too confusing. Just make everything public.
* daml-lf/archive: Push protobuf source tarballs into `proto_jars`.
* Bazel: Add comments to the various parts of `proto_jars`.
* daml-assistant: Do unpleasant things with `location` in Bazel.
Some features, in particular daml-lf encoding features, don't make any sense to have an associated CPP flag. I made the CPP flag optional and removed these unnecessary feature flags (based mostly on whether the flags were used in the standard library).
changelog_begin
changelog_end
* Adapt to new desugaring for choice observers.
update hash of ghc patch.
changelog_begin
changelog_end
update ghc patch to final version
update stack-snapshot hashes for ghc-lib(-parser)
update stackage_snapshot.json, following `bazel run @stackage-unpinned//:pin`
expose Optional constructors for desugared code to use
adapt LFConversion to expect a 4-tuple for a desugared choice def/sig
update LFConversion for choice-observers
first example using new choice observer syntax.
fix scala type checker to have correct scoping rules for choice-observers
remove comment from example which says it is broken
improve variable names
improve tests for choice-observer clause
only test choice-observers SINCE 1.dev
add jq queries for choice observeres
make positive statement in jq test which checks choice obserers are present
test behaviour of choice observers
squash me
typo
* test more choice-observer divulgence
* Update documention for choice observers.
changelog_begin
Support choice observers in 1.dev
changelog_end
* fix docs build
* fix daml docs choice-observers example
* address comments: rewording text
* annotate choices observers as early-access in documention
* split out documentation code-snippets which require --target=1.dev
* final tweaks to documentation text
* Rewrite multiple binding lets sequentially.
This PR enforces a sequential evaluation and dependency on
multiple-binding lets, by rewriting,
let x1 = e1
x2 = e2
...
xn = en
in b
Into a chain of single-binding let expressions,
let x1 = e1 in
let x2 = e2 in
...
let xn = en in
b
And likewise, rewriting multi-binding let statements in a "do" block,
do
...
let x1 = e1
x2 = e2
...
xn = en
...
Into single-binding let statements,
do
...
let x1 = e1
let x2 = e2
...
let xn = en
...
This PR fixes#6788 and adds a bunch of tests.
This is a bugfix, but it may break existing code that relies on
out-of-order let bindings. The suggested fix is to simply reorder
the let bindings, placing them in order of their dependency.
CHANGELOG_BEGIN
- [DAML Compiler] The DAML compiler now enforces sequential
ordering for ``let`` expressions with multiple bindings.
This fixes a bug where ``let`` expressions would be evaluated
in the wrong order.
CHANGELOG_END
* Update compiler/damlc/daml-preprocessor/src/DA/Daml/Preprocessor.hs
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* adjust last binding behavior
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* DAML-LF: Add interning for type to DAML-LF 1.dev
We add two new features to DAML-LF 1.dev:
* a per package list (or table) of `Type` messages, and
* a new case in the `Type` message which is an index into this table.
In combination, these two features can be used to allow DAML-LF
encoders to perform hash-consing of `Type` messages. We also change the
Haskell implementation of our DAML-LF encoder to do exactly that when
targetting DAML-LF 1.dev.
Doing this has a few benefits:
1. The DALFs produced by `damlc` get smaller: I've seen a case where
the size dropped from 69MB to 45MB.
2. DAML-LF decoders need to decode less data.
3. Decoded packages use less memory because identical structures are
now shared. This is particularly helpful in situations where we need
to keep the interface (or signature) of a package in memory for a
long time.
This PR mostly takes care of the Haskell implementation. However, we
need to make the Scala implementation of the decoder aware of the new
features as well since we have tests that load DAML-LF 1.dev into the
engine. A decoder and _targeted_ tests on the Scala side will follow
in a separate PR.
CHANGELOG_BEGIN
CHANGELOG_END
* Make jq tests aware of type interning
CHANGELOG_BEGIN
CHANGELOG_END
* Improve jq test
CHANGELOG_BEGIN
CHANGELOG_END
* Apply Remy's suggestions
Co-authored-by: Remy <remy.haemmerle@daml.com>
* Improve the imperative bits
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Remy <remy.haemmerle@daml.com>
* Make GHC recognise our ($) operator.
Fixes#4555 by moving ($) to GHC.Base and giving it a levity polymorphic
signature, as GHC expects. Added a regression test.
changelog_begin
changelog_end
* Update line numbers for debug...
* Fix `daml test-script` tests
changelog_begin
changelog_end
* fmt for the format gods
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Allow for lets before letrec transformation.
Fixes#7953 by adjusting the letrec transformation to handle
(optional) nonrecursive lets before the letrec binding, and adds
a regression test.
changelog_begin
changelog_end
* typo
* apply martin suggestions
* Perform kind-checking in DAML compiler.
This PR avoids generating invalid kinds (i.e. kinds of the form k ->
Nat) during LF conversion, and adds a small "kind checking" step
whenever a type variable is introduced in the LF typechecker (since the
only way to get invalid kinds is to introduce them in a `forall`).
Right now there's no way to test that both the typechecker & the
conversion raise an error here, and in general, we try to always push
our LF type errors into GHC type errors or LF conversion errors. This
is something we can work on (adding actual LF typechecker tests). But
also, I verified manually that the type checker raises the error, in
the absence of the changes to LF conversion.
Ok, last point: The test case here has a weird location, but I tried and
couldn't figure out how to get a better location. I think this is a
general problem with the GHC Core representation?
changelog_begin
changelog_end
* Add more kind checks and restrict test version.
* fix test again
* Add a warning for GHC.Types.Symbol
CHANGELOG_BEGIN
- [DAML Compiler] Added a warning for references to
the GHC.Types.Symbol kind since these cannot be
preserved across data-dependencies.
CHANGELOG_END
* lint
* Address review comments
* fix LFNameCollisions test
* improve LFNameCollisions fix
* damlc: fix: relative output path relative to cwd
This fixes#7913. Build output path were considered relative to the
project root instead of the current working directory.
CHANGELOG_BEGIN
CHANGELOG_END
* adding a test
* daml ledger: implementation of ledger commands
Implementation of the remaining daml ledger commands via HTTP JSON
service endpoints instead of gRPC.
Fixes#4824 .
CHANGELOG_BEGIN
[daml assistant] `daml ledger` commands can now also be run against the JSON API instead of the gRPC API.
CHANGELOG_END
* damlc: Check DAML-LF pattern matches for exhaustiveness
`damlc` has always produced exhaustive pattern matches in DAML-LF since
GHC adds a default branch with a call to `error` message as soon as a
pattern match is not exhaustive. It was a complete oversight on our
side that we did not enforce this properly in DAML-LF. Since `damlc`
has never produced non-exhaustive pattern matches, enforcing this now
and for all DAML-LF versions is only theoretically a breaking change,
namely if people hand-crafted DAML-LF, but not practically.
This check is as under-tested as the rest of our Haskell implementation
of the DAML-LF type checker. Well, all our other tests implicitly check
that the type checker does not give false errors. However, we have no
tests ensuring that the type checker is not too permissive. Fixing this
situation would require a big time investment since we currently don't
have a simple way to produce DAML-LF without going through GHC, which
will always produe well-typed DAML-LF.
I will update the DAML-LF specification wrt pattern matching
exhaustiveness in a separete PR.
This PR does not have a changelog entry since there's no impact for our
users.
CHANGELOG_BEGIN
CHANGELOG_END
* Make check linear in match size not constructor number
CHANGELOG_BEGIN
CHANGELOG_END
* Move lookupWithIndex in Data.List.Extended
CHANGELOG_BEGIN
CHANGELOG_END
* Implement the suggestions
CHANGELOG_BEGIN
CHANGELOG_END
* Haskell: Add hlint rule to suggest foldl' over foldl
`foldl` is lazy in a way that almost never is what you want since it
can cause space leaks without any benefit. `foldl'` does not have this
problem. See https://www.well-typed.com/blog/2014/04/fixing-foldl/ for
more details.
CHANGELOG_BEGIN
CHANGELOG_END
* Fix all existing occurrences of foldl
CHANGELOG_BEGIN
CHANGELOG_END
Currently, we're warning that both extensions might not work with
`data-dependencies`. However, we have tests that demonstrate that both
extensions actually do work with `data-dependencies`. Since there's
been customer demand to remove these warnings, we'll do so.
CHANGELOG_BEGIN
[damlc] Don't warn anymore that the language extensions TypeOperators
and UndecidableInstances might not work with `data-dependencies`.
CHANGELOG_END
The packaging test suite has become just so big that it regularly
exceeds its 15 min timeout. There are some deeper issues here, for
instance that we set up tons of tiny DAML projects and call
`daml build` on each of them. Each of those builds initializes a
package database, which is one of the things that seem to take
noticable time. Unfortunately, fixing these issues is a bigger effort.
This PR is more of a band aid rather than a proper solution: split the
packaging tests into two parts: the packaging tests and the tests for
data-depenendencies. Effectively, this amounts to giving the old
packaging test suite a 30 min time budges, but at least the two parts
can now be run in parallel.
CHANGELOG_BEGIN
CHANGELOG_END
Currently, the Haskell implementation of the DAML-LF type checker
first branches on the pattern and then on the type of the scrutinee.
This PR changes it to first branch on the type of the scrutinee and
then on the pattern. This allows for destructing the type of the
scrutinee only once intead of repeating it for each pattern. This
should be good for performance, which is a nice side effect of this
change.
The main reason why I'm changing this is because we want to implement
an exhaustiveness check. This seems rather complicated to achieve with
the current implementation and will be significantly easier after this
change.
This PR is purely a refactoring and does not change the semantics of
amnything. In particular, it does not touch the decision that default
patterns match on anything, even no other pattern would match on the
value.
CHANGELOG_BEGIN
CHANGELOG_END
On request by @hurryabit, this PR changes the representation of
overlap modes by moving it to the type-level. Since the value-level
encoding never made it into a stable release, this isn't a breaking
change. Also, the data-dependency and roundtrip tests are unchanged,
only the daml-test-files overlap mode test had to be updated.
changelog_begin
changelog_end
Currently, `damlc` compiles a record projection section `(.foo.bar)`
into
```
getField @"bar" . getField @"foo"
```
Since we don't inline the `.`
operator, this is slower than it could be.
This PR changes the compilation scheme to produce
```
\record -> getField @"bar" (getField @"foo" record)
```
This is significantly faster since it avoids a couple of function
applications.
My micro benchmarks show a speedup of 1.8x for a single application of
`(.foo.bar)`. For a chain of length 3, as in `(.foo.bar.baz)`, the
speedup is even 2.3x.
This PR does add any new tests since the existing tests, particularly
the ones in `Records.daml`, already cover that area.
CHANGELOG_BEGIN
[daml] Performance improvements for record selector sections such as
`(.foo.bar)`.
CHANGELOG_END
* damlc: Use fresh names when compiling builtins
Currently, we're always using the variables names `v1`, `v2`, ... for
the lambdas we introduce during the conversion of partially applied
builtins to DAML-LF. This can lead to problems when the variable name
is already in use. The test cases used to fail because of the usage of
`v2`.
This PR fixes the issue by properly generating fresh names. There's no
test case for type variables since I don't know how to trigger an
issue. Fixing it seems a good idea nevertheless.
CHANGELOG_BEGIN
CHANGELOG_END
* Add Sofia's suggestions
CHANGELOG_BEGIN
CHANGELOG_END
* Fix a nasty typo
Co-authored-by: Sofia Faro <sofia.faro@digitalasset.com>
* Fix more issues pointed out by Sofia
CHANGELOG_BEGIN
CHANGELOG_END
Co-authored-by: Sofia Faro <sofia.faro@digitalasset.com>
* Cache computation of top-level values at definition level
Earlier the computation of a top-level value was only cached at the
use-site in SEVal. This introduces SDefinition which contains the same
mechanism as SEVal to cache the computation.
As expected this does not impact performance much:
before: CollectAuthority.bench //daml-lf/scenario-interpreter/CollectAuthority.dar CollectAuthority:test avgt 40 44.267 ± 0.728 ms/op
after: CollectAuthority.bench //daml-lf/scenario-interpreter/CollectAuthority.dar CollectAuthority:test avgt 40 43.693 ± 0.702 ms/op
What this does have a significant impact is on reducing the number of distinct
SValues for things like type class dictionaries etc, so that now we have one
SValue per dictionary rather than one per SEVal.
CHANGELOG_BEGIN
CHANGELOG_END
* Address code review
* Fix speedy tests
* Add MINIMAL pragma support in data-deps.
CHANGELOG_BEGIN
- [DAML Compiler] MINIMAL pragmas are now imported correctly
in data-dependencies.
CHANGELOG_END
* fix test
* Review comments
* Update compiler/damlc/daml-lf-conversion/src/DA/Daml/LFConversion.hs
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* Refactor fun dep and overlap mode implementations.
This PR moves the functional dependency and overlap
mode encoding/decoding functions to a single module,
separate from the rest of LF conversion or
data-dependencies, in preparation of adding more
annotations of this sort (e.g. MINIMAL).
This involves a small amount of refactoring to get
the types to line up... It should be a little easer
to write some roundtrip tests for these now.
I'm not super satisfied with how much fun dep / overlap
mode logic is still left in LFConversion.hs and
DataDependencies.hs, but this is a step in the right
direction at least.
changelog_begin
changelog_end
* Rename Encoding to MetadatEncoding
That `setFieldPrim` is so far away from `getFieldPrim` has bugged me
for a while now. I _strongly_ feel that they should be next to each
other.
There are also a few outdated comments that are brought up to date.
CHANGELOG_BEGIN
CHANGELOG_END
This PR adds a couple of tests that ensure that various syntactic
variants of record projection all get translated into the according
DAML-LF primitive as soon as we know the record type and field name.
This PR also fixes some inconsistencies in the translations of
`getField` and `getFieldPrim`. The change for `getField` does not have
any impact if the simplifier is run since the simplifier would perform
the inlining for a partially applied `getField` we perform here.
Nevertheless, performing this inlining in the conversion to DAML-LF has
some advantages. First of all, we also run it in cases where the
simplifier is turned off, like incremental computation. Second, this is
such a crucial optimization that I want to be as sure as possible that
it is run. Third, doing the inlining in the conversion is cheap and
removes a bit of load from the simplifier. Fourth, the consistency with
the other record primitives is quite nice too.
CHANGELOG_BEGIN
CHANGELOG_END
* Fix scenario service vs struct projections bug
In a recent change, we have sped up the projection from structural
records by means of an inference in the DAML-LF type checker. This
change was made under the assumption that users of the DAML interpreter
run through package validation before compiling to the internal Speedy
AST. Unfortunately, that assumption was wrong and not covered by our
existing tests. Manually testing of a new release candidate reminded us
of the fact that the scenario service skips package validation for the
sake of faster response times in the IDE.
This PR drops the assumption that package validation is always run.
Instead, we add the old implementation of struct projection, which works
without DAML-LF type checking, back and use it whenever the AST has not
been annotated with the information inferred by the type checker. We do
the same for struct updates.
We improve test coverage by _additionally_ running the `damlc`
integration tests without package validation for the latest stable
version of DAML-LF and DAML-LF 1.dev. These tests would have caught the
issue we only discovered during manual testing.
CHANGELOG_BEGIN
CHANGELOG_END
* Add some explanations
CHANGELOG_BEGIN
CHANGELOG_END
* daml assistant: cleanup of daml ledger commands
This is a cleanup of the Helper/Ledger.hs module in preparation for
further implementations of `daml ledger` commands against the JSON API.
In particular the module Compiler/Fetch.hs is removed from daml-compiler
and its contents moved over the Helper/Ledger.hs. Some renaming and
reorganization is done for clarity.
CHANGELOG_BEGIN
CHANGELOG_END
`Symbol` is the kind of type-level strings. We use type-level strings
as part of our record system. That's why we need the `Symbol` in the
first place. However, one can abstract over record fields using the
`HasField` typeclass without directly using the `Symbol` kind. Thus,
there's is no need for our users to ever use it. In fact, they
most likely don't want to use it since it does work work with
data-dependencies and we have no plans to support it in that way.
Given that `Symbol` is not necessary and doesn't work in all cases,
let's hide it from the docs so that nobody gets the idea to use it.
CHANGELOG_BEGIN
CHANGELOG_END
* Add Enum and Bounded instances to DA.Date
CHANGELOG_BEGIN
[DAML StdLib] Add Enum and Bounded instances to DA.Date
CHANGELOG_END
* Hide internal date functions in docs
* Fix line numbers
* Export Date<>Int conversion functions rather than hiding
* Update compiler/damlc/daml-stdlib-src/DA/Date.daml
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Offset the Date enum to make it zero-based
* Apply suggestions from code review
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* Improve tests
* Incorporate Martin's feedback
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
Also adds a small test.
changelog_begin
- [DAML Compiler] Similar to functional dependencies, the
compiler now adds overlapping instance pragmas into the
DALF/DAR files. This way, overlapping instances pragmas
will be preserved when importing typeclass instances
via data-dependencies.
changelog_end
* Add overlap mode annotations during LF conversion.
This PR adds an overlap mode binding `$$om$fFoo...` during LF conversion
per typeclass instance `$fFoo...` that uses an overlap mode pragma. The
idea is that we can then pick these up during data-dependencies
(left to a separate PR).
This PR also adds a test to make sure we're capturing this information
correctly.
changelog_begin
changelog_end
* git shrapnel
* choice observers, WIP
changelog_begin
changelog_end
fix generator driven test
Node.isReplayedBy, consider observers
add observers to NodeExercise in transaction.proto
add observers to TemplateChoice in Ast.scala
add observers to LF .proto, and Haskell Ast for TemplateChoice
reinstate trailing // for better format
fix validate tests
fix haskell LF decoder when choice-observers field is missing in .proto
fix build
make choice-observers optional in scala AST
make choice-observers optional in Haskell Ast
address comments from Remy and Martin
more review comments
check TransactionVersions.minChoiceObservers in Transaction encode/decode
featureChoiceObservers, and check in haskell type-checker
improve speedy Compiler for empty choice-observers
extend scala LF decoder for optional choice observers
extend scala parser for choices to allow optional choice-observers clause, and test
rename new field in scala Ast -> "choiceObservers"
var rename
extend TypingSpec tests for choice-observers. also add missing negative test for controllers
switch from keyword "ob" to identifier "observers" in scala parser choice syntax
add TODO for featureChoiceObservers to be part of DAML 1.9 (issue 7139)
* replace "NICK" comment markers with "FIXME #7709" comment markers
I tried a compiler with these new warnings on a giant codebase and I
turned out they are _extremely_ noisy. There are basically two things we
want to warn about:
1. Usage of the promoted kinds and types coming from the `DA.Generics`
module.
We already have a warning that importing `DA.Generics` will break
data-dependencies. Adding a warning to every single use site of its
exports seems rather excessive and doesn't add any new information.
2. Usage of the `Symbol` kind and type-level strings.
The `Symbol` kind seems to work better with data-dependencies than I
expected although it is erased into kind `*` during conversion to
DAML-LF. This is for two reasons: (1) The only _legal_ way to
introduce a type variable of kind `Symbol` is by means of the
`HasField` typeclass (you can technically get your hands on the
`Symbol` kind directly, but you need work around not being able to
import the internal module `GHC.Types`). (2) In data-dependencies,
we reconstruct type variables of kind `*` not as kind `*` but rather
ask GHC to infer their kinds (via
[`UserTyVar`](https://hackage.haskell.org/package/ghc-8.10.1/docs/src/GHC.Hs.Types.html#UserTyVar)).
This means that every type variable that was originally of kind
`Symbol` will be reconstructed at that kind again since the
necessary `HasField` constraint will force GHC to infer it.
I'm totally aware that it looks a lot like this works by accident
but I'm not completely opposed to making it a feature after the
fact. Before we make any decisions in this regard though, we should
decide on what uses of kind `Symbol` we want to make compatible with
data-dependencies. For instance, functions of types like
overField: forall x r a. HasField x r a => (a -> a) -> r -> r
might be something we want to support. We also need to support
constraints of the form `HasField "abc" ...` with a concrete
type-level string everywhere. The current implementation would have
warned about them. Thus, I see two open questions around the
`Symbol` kind: (1) Do we want to allow `HasField x r a`, where `r`
is a type variable and _not_ a type-level string, to be a superclass
constraint? (2) Do we want to allow the same constraint in the
context of a typeclass instance?
One thing we should definitely not allow is using the `Symbol` kind
directly under its name `GHC.Types.Symbol`, which is always in scope
for our record preprocessor. I will add an error when users try to
access that kind in a separate PR.
CHANGELOG_BEGIN
[DAML Compiler] The warning about advanced types combined with type
classes in a way that is supported by data-dependencies has been removed
again.
CHANGELOG_END
* Functional dependency support in data-dependencies
(WIP)
* Add test.
changelog_begin
- [DAML Compiler] Functional dependencies are now saved
by the DAML compiler in the DALF file / DAR package. When
importing a file with the functional dependency data via
data-dependencies, these will be picked up automatically.
changelog_end
* Move CallStack, HasCallStack docs to DA.Stack
This PR only modifies the docs. In particular, it:
- moves the `CallStack` and `HasCallStack` docs to `DA.Stack`
- gives an example of adding the `HasCallStack` constraint
- hides the rest of `GHC.Stack.Types` from the docs
Rationale: `GHC.Stack.Types` has a lot of `TextLit` stuff that
we don't want people to use directly, and we want people to
import `DA.Stack` instead anyway.
changelog_begin
changelog_end
* commit unsaved changes, doh
* grammar
Updating the expected dignostics for `damlc`'s integration tests can
be quite tedious. This PR adds a `sed` script to simplify it a bit.
See the included readme for details.
CHANGELOG_BEGIN
CHANGELOG_END
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
