This adds an option to specify a pattern such that only tests containing
the given pattern in their name will be executed.
Fixes#13534.
CHANGELOG_BEGIN
CHANGELOG_END
Process:
- `git ls-files | xargs sed -i 's/DAML/Daml/g'`
- `git add -p`
To review:
- Check for false positives by carefully reviewing the diff in this PR.
- Check for false negatives with `git grep DAML`.
CHANGELOG_BEGIN
- Removed all traces of DAML. This may affect error messages and debug
outputs.
CHANGELOG_END
This is needed so shared libraries are properly resolved and this
actually works outside of our build. Same issue that broke
damlc_legacy originally and we had someone trying to use cpp on their
own project (whether they should is another question but having it
half working is even worse).
I don’t know how to write a test for this unfortunately. It would only
fail if our nix store is not available which is pretty hard to
simulate. I could spin up a docker image or something but that doesn’t
seem worth the trouble.
fixes#13100
changelog_begin
changelog_end
New year, new copyright, new expected unknown issues with various files
that won't be covered by the script and/or will be but shouldn't change.
I'll do the details on Jan 1, but would appreciate this being
preapproved so I can actually get it merged by then.
CHANGELOG_BEGIN
CHANGELOG_END
* Set --enable-scenarios to False by default
changelog_begin
changelog_end
* Enable scenarios for shake test
* Add --enable-scenarios=yes for //compiler/lsp-tests
* Add enable_scenarios arg to rules_daml/daml.bzl helpers
* daml_compile
* daml_build_test
* daml_test
* Add enable_scenarios to ledger/test-common helper da_scala_dar_resources_library
* Add --enable-scenarios=yes for //ledger/test-common
* Remove unused scenario in //ledger/test-common PingPong test
* Add --enable-scenarios=yes for //daml-lf/tests
* Add --enable-scenarios=yes for //language-support/java tests
* Add --enable-scenarios=yes for group-chat example
* Add --enable-scenarios for //ledger/sandbox-perf LargeTransaction test
* Add --enable-scenarios=yes for //docs tests
* Add --enable-scenarios=yes for //daml-lf/scenario-interpreter tests
* format bazel
* Add --enable-scenario=yes for 'daml_doc_test's
* Add --enable-scenarios=yes for DamlDocTestIntegration
* Add --enable-scenarios=yes for DamlcTest
* Add --enable-scenarios=yes for Test/DataDependencies
* Add --enable-scenarios=yes for daml-ghc-deterministic.sh
* Add --enable-scenarios=yes for Test.IncrementalBuilds
* Add --enable-scenarios=yes for tests:memory-bond-trading and tests:memory-examples
* Add --enable-scenarios=yes for daml-assistant/integratio-tests
* Add --enable-scenarios hidden flag
* Fail LFConversion when a scenario is defined and --enable-scenarios=no
* Remove unused optIsGenerated=True test cases
* Refactor getIntegrationTests
* Add no-scenarios-enabled tests
* Add enable-scenarios flag to scenario-service server
* Add test ensuring that scenario-returning functions are still allowed
* Remove 'enable scripts' option (--daml-script)
* Add --scripts synonym to --scenarios
* Rephrase scenarios flags descriptions
changelog_begin
changelog_end
This seems like a more sensible default. There are really only very
few places where it makes sense to do things automagically (mainly the
IDE). For everything else we might just end up wasting time by
compiling stuff we don’t need.
changelog_begin
changelog_end
Also drops the weird Base module and the always empty tags (yet
another reason why I want to burn our own logging lib with fire).
changelog_begin
changelog_end
* record dot updates: update to new ghc-lib-parser
This updates the ghc-lib-parser library featuring record dot updates and
adds tests for the new feature.
CHANGELOG_BEGIN
CHANGELOG_END
* update snapshot after pin on windows
* added a test for error locations
* nested record puns test
* update ghc commit
* update of stack dependencies (linux)
* update stack snapshot(windows)
* daml build: add a --access-token-file for remote dependencies
This adds a `ledger.access-token-file` field in the `daml.yaml` project
file and a `--access-token-file` flag to `daml build` to authorize
querying/fetching of remote dependencies.
CHANGELOG_BEGIN
[daml build] A new flag `--access-token-file` is added for the `daml
build` command. It allows the specify the path to an access token to
authenticate against the ledger API. This is needed if the project
depends on a remote Daml package hosted on such a ledger. Alternatively,
the path to the token can also be specified in the `daml.yaml` project
file under the `ledger.access-token-file` field.
CHANGELOG_END
* daml pkg: split installation of deps and package db inititialization
This is the next step for the daml package manager program #8976.
This splits the installation of dependencies from the initialization of
the (ghc) package database.
CHANGELOG_BEGIN
CHANGELOG_END
As a first step for the daml package manager, we move all dalf files
from (data-)dependencies to a new `.daml/dependencies` directory.
CHANGELOG_BEGIN
CHANGELOG_END
* damlc: incremental package db initialization
We keep a hash over all dependencies of a project in the package
database metadata and only recompute the package database if a
dependency changes, i.e. the computed hash changes.
Fixes#4413.
Fixes#8409.
CHANGELOG_BEGIN
CHANGELOG_END
* using Fingerprint
* added tests
* format
* use SdkVersion instead of hardcoded version
* added a reference in tests
* factored out project file template
* damlc: Don't warn on ExplicitNamespaces extension
Since we allow the `TypeOperators` extension, which implies
`ExplicitNamespaces`, there is no point in warning in warning about
the latter.
There's not much to test for this wrt to `data-dependencies` since we
don't reconstruct export lists.
CHANGELOG_BEGIN
damlc: Don't warn on ExplicitNamespaces extensions anymore.
CHANGELOG_END
* Fix a test expecting a warning about ExplicitNamespaces
CHANGELOG_BEGIN
CHANGELOG_END
* Bundle hpp with damlc.
This PR eliminates the red squiggly lines you get when opening up the
standard library in daml studio (e.g. after a Go To Definitien).
(When CPP is used, Go To Definition is still pointing to the wrong place,
because the line numbers are messed up. But it's better than having a
million error messages.)
We could also remove --cpp flag in a separate PR, though that may be
considered a breaking change.
changelog_begin
changelog_end
* cleanup locateRunfiles jank
* Revert "cleanup locateRunfiles jank"
This reverts commit 82552003ae.
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
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
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 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>
This is clearly a breaking change but triggers are still alpha so we
can get away this (confirmed with Bernhard).
changelog_begin
- [DAML Trigger] Daml.Trigger.Assert now uses DAML Script instead of scenarios.
changelog_end
* Extend the scenario service with DAML Script support
This adds most of the infrastructure for running DAML Script via the
scenario service which means it runs as part of DAML Studio and `daml
test`. This is hidden behind a feature flag so we can land this and
parallelize the remaining tasks. The main things that are missing are:
1. `createAndExerciseCmd` and `exerciseByKeyCmd`.
2. Party management needs some work and listing parties is
unsupported.
3. Time management
4. Potentially some better error handling (we need to go through
SResult and SError and see what is relevant for us).
Overall, it is already in a very usable state and there is a decent
range of tests.
closes#3688
changelog_begin
changelog_end
* Update compiler/damlc/daml-ide-core/src/Development/IDE/Core/Rules/Daml.hs
Co-authored-by: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Fix name for actor system and pool
changelog_begin
changelog_end
Co-authored-by: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Upgrade nixpkgs revision
* Remove unused minio
It used to be used as a gateway to push the Nix cache to GCS, but has
since been replaced by nix-store-gcs-proxy.
* Update Bazel on Windows
changelog_begin
changelog_end
* Fix hlint warnings
The nixpkgs update implied an hlint update which enabled new warnings.
* Fix "Error applying patch"
Since Bazel 2.2.0 the order of generating `WORKSPACE` and `BUILD` files
and applying patches has been reversed. The allows users to define
patches to these files that will not be immediately overwritten.
However, it also means that patches on another repository's original
`WORKSPACE` file will likely become invalid.
* a948eb7255
* https://github.com/bazelbuild/bazel/issues/10681
Hint: If you're generating a patch with `git` then you can use the
following command to exclude the `WORKSPACE` file.
```
git diff ':(exclude)WORKSPACE'
```
* Update rules_nixpkgs
* nixpkgs location expansion escaping
* Drop --noincompatible_windows_native_test_wrapper
* client_server_test using sh_inline_test
client_server_test used to produce an executable shell script in form of
a text file output. However, since the removal of
`--noincompatible_windows_native_test_wrapper` this no longer works on
Windows since `.sh` files are not directly executable on Windows.
This change fixes the issue by producing the script file in a dedicated
rule and then wrapping it in a `sh_test` rule which also works on
Windows.
* daml_test using sh_inline_test
* daml_doc_test using sh_inline_test
* _daml_validate_test using sh_inline_test
* damlc_compile_test using sh_inline_test
* client_server_test find .exe on Windows
* Bump Windows cache for Bazel update
Remove `clean --expunge` after merge.
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* Fix haddock typo
* Daml REPL - use data dependencies
Without this a DAR that has a transitive dependency on another DAR
cannot be loaded into the REPL since the interfaces are missing, with
data-dependencies they are reconstructed.
CHANGELOG_BEGIN
- [DAML REPL] The provided DAR is now loaded as a data-dependencies,
meaning that the REPL supports loading DARs with transitive
dependencies.
CHANGELOG_END
* REPL test - use indirect DAR dependency
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* Prefix IDE include paths with project root
As described in #6174, `--include` is broken pretty badly in the IDE
atm. LSP works based on absolute file paths so if you have a relative
include dir you run into two issues:
1. You end up with two GHC sessions e.g, one for `/multidir` and one
for `.`. That results in fun type errors like “Couldn’t match expected
type `Text` with actual type `Text`”.
2. The same file can end up being represented twice. Apart from being
horribly inefficient, this breaks as soon as we try to build a DALF
since the function for constructing that (correctly) explodes when
there are two files with the same module name.
This change does not break `daml build` since the project root is
relative there.
fixes#6174
changelog_begin
- [DAML Studio] Fix an issue where use of the `--include` option
resulted in various confusing type errors. See
https://github.com/digital-asset/daml/issues/6174
changelog_end
* Stop wasting my time hlint
changelog_begin
changelog_end
* Add a module-prefixes field to rename all modules in a pkg
This PR adds a `module-prefixes` field to `daml.yaml` a a shorthand
for specifying a `--package` flag that renames all modules in a
package to have the same prefix.
The docs are updated to describe how you can use this field and there
is a test case that makes sure it works.
fixes#4948
changelog_begin
- [DAML Compiler] You can now use the new ``module-prefixes`` field in
``daml.yaml`` to add a prefix to all modules from a dependency. This
is particularly useful for handling colliding module names during
upgrades. See
https://docs.daml.com/daml/reference/packages.html#handling-module-name-collisions
for more information.
changelog_end
* Update compiler/damlc/daml-opts/daml-opts-types/DA/Daml/Options/Packaging/Metadata.hs
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
* Improve docs and fix broken suggestion
changelog_begin
changelog_end
Co-authored-by: Martin Huschenbett <martin.huschenbett@posteo.me>
This PR finally puts together the refactorings from the last two PRs:
1. We now write out a JSON file (because JSON seems like a reasonable
choice and it doesn’t really matter) containing the main unit ids
when setting up the package db.
2. When initializing the GHC session, we now simply read that file
instead of reading the daml.yaml again and parsing all
dependencies and data-dependencies again.
changelog_begin
changelog_end
This is a first step in probably a series of PRs to cleanup the
packaging logic.
There is no change in functionality (or at least none that is
intended). The changes boil down to two things:
1. Add a `DependencyInfo` type that stores the various maps and has
detailed comments what exactly is in each map and hopefully somewhat
descriptive field names.
2. Move a lot of the logic in `createProjectPackageDb` into various
helper functions.
There is definitely a lot more cleanup and refactoring that we can do
here but I’ll try to keep it in manageable chunks.
changelog_begin
changelog_end
This is a spin off from the work for making module prefixing
work. There I wanted to be able to use the `GeneratePackageMap` rule
to get access to the modules in an LF package which requires to be in
an Action rather than in IO.
This resulted in a much larger refactoring than I expected, so here is
a list of changes to ease review:
1. I’ve split off Development/IDE/Core/RuleTypes/Daml.hs into its own
Bazel targets to avoid cycles. This allows us to use a rule without
depending on the implementation of that rule.
2. Development/IDE/Core/IdeState/Daml.hs has moved into its own Bazel
target. There is a lot of stuff that needs `withDamlIdeState` now
since the `ghcide` `initialise` function does not add our Shake rule
for getting the GHC session and making all of that depend on
damlc:lib creates a mess.
3. The actual logic of the initialization has stayed the same but
moved into a rule in Development/IDE/Core/Rules/Daml.hs.
4. As mentioned above, a few things that could previously get away
with only the rules provided by ghcide now need our own rules so
they switched to `withDamlIdeState`. This mainly affects `damlc
docs`.
5. Making daml-docs work with the ofInterestRule is a bit tricky.I did
find the issue and included the fix but also disabled the
ofInterestRule since it really does not make sense to generate Core
in the background.
changelog_begin
changelog_end
* Depend on LF version specific daml-libs
* daml-script.dar build multiple LF versions
CHANGELOG_BEGIN
[DAML Script] The `daml-script` library is now available in multiple LF
versions, namely 1.7, 1.8, and 1.dev.
CHANGELOG_END
* daml-trigger.dar build multiple LF versions
[DAML Triggers] The `daml-trigger` library is now available in multiple
LF versions, namely 1.7, 1.8, and 1.dev.
* Keep daml-script.dar available for tests
* Keep daml-trigger.dar available for tests
* daml-libs LF versions integration test
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* Use package metadata instead of file names to infer unit ids
This PR adds a function that abstracts over whether we get metadata
from a filename (< 1.dev) or directly from the LF metadata.
There is more work to be done here, in particular, I want to clean up
the hacks around daml-prim/daml-stdlib but I’ll leave that for a
separate PR.
changelog_begin
changelog_end
* Update compiler/daml-lf-ast/src/DA/Daml/LF/Ast/Util.hs
Co-Authored-By: associahedron <231829+associahedron@users.noreply.github.com>
* Refactor getUnitId
Co-authored-by: associahedron <231829+associahedron@users.noreply.github.com>
* Refactor handling of package names and versions
This is a preparatory refactoring PR in preparation for propagating
package metadata into DAML-LF. There are no actual changes in here.
Primarily the changes consist of 3 things:
1. In options, we split the `optMbPackageName` field which previously
contained the unit id into `optMbPackageName` and
`optMbPackageVersion`.
2. We use newtypes for names and versions and try to keep them pretty
much everywhere (the only place missing is `splitUnitId`, I’ll do that
separately).
3. We use `UnitId` where we want `name-version`.
As was probably to be expected, this surfaced some minor issues. They
are pretty much exclusively in debugging or “internal” commands so
I’ve mostly just added notes/todos.
changelog_begin
changelog_end
* cry about applicativedo
* Switch to HashSet/HashMap for NormalizedUri/NormalizedFilePath
This matches the change to ghcide in
https://github.com/digital-asset/ghcide/pull/420. Now that we have
optimized Hashable instances it makes sense to use them as much as
possible.
changelog_begin
changelog_end
* debug windows crap
* Fix a bug in vr scenario notifications
* Revert "debug windows crap"
This reverts commit f58fdb92c1.
* attempt to fix windows
who are we kidding, this is not going to work
* Support multiple-packages in `damlc ide`
changelog_begin
- [DAML Studio] You can now open DAML Studio in the root of a
multi-package project instead of opening it separately for each
package. Take a look at the documentation for details on how to set
this up.
changelog_end
There are a few caveats here:
1. You need a ``daml.yaml`` in the root of your project directory. I
think this is somewhat sensible but we should add a warning to VSCode
if you open it in a directory that does not have a ``daml.yaml`` (in a
separate PR).
2. Changes are not picked up accross dependencies. This is a larger
undertaking and given the current setup simply impossible (we don’t
know that the source files of one package belong to the DAR referenced
in the ``dependencies`` field of the other package. We can make this a
bit better by at least detecting that the ``.dar`` has changed but
let’s do that separately.
3. Since ``daml init`` runs once on startup, it will run in the root
directory instead of initializing the package db of the individual
packages. This is fixable but will conflict with #4391 so let’s
address this separately.
I’ve added docs to the daml studio section that explain the caveats.
* Use the proper sdk version in lsp-tests
`fakeDynFlags` has been removed from ghcide. We still need it since we
set up our environment in weird ways and want it to be platform
independent so this PR just copies the definition into `daml`.
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
