* damlc: Allow package IDs in data-dependencies.
This is the next step outlined in issue #8976. If package id's are
present in the `data-dependency` section of the daml.yaml file, we try
to fetch them (and their transitive dependencies) from the default
ledger of the project.
CHANGELOG_BEGIN
CHANGELOG_END
This untangles the dependency structure a bit so that //daml-lf no
longer ends up depending on daml script and sandbox and similar crap
which should improve build times in general.
changelog_begin
changelog_end
This only compiles `damlc-bootstrap` as a Haskell binary and `damlc` is
a simple symlink with additional runfiles.
We now need to define `damlc@ghci` manually since it is no longer
defined automatically. The manual definition was tested with
```
$ bazel run //:damlc@ghci --define ghci_data=True
> :main ide -d
```
changelog_begin
changelog_end
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
* 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.
At some point in time, `daml-licenses` was supposed to list the licenses
for all of our Haskell dependencies. It's not been updated in ages, and
we now have a reliable way to get at all our dependencies.
This is arguably a bit weird since the command is `daml damlc license`,
and it lists licenses for everything (`daml license` would make more
sense), but it seems a lot better to give a correst superset than an
incorrect list.
Perhaps we can move the command to `daml license` at some point, but I'd
see that as a separate step. (That would technically be a breaking
change, but I think this one might be OK.)
CHANGELOG_BEGIN
CHANGELOG_END
* Factor out tar/gzip reproducibility flags
* use mktgz in package-app
* Bazel managed tar/gzip
* Remove quiet = True
As stated in the comment this is no longer required with Bazel >= 3.0.
* Build package-app as a sh_binary
This way Bazel will manage the runtime dependencies tar, gzip, mktgz,
and patchelf.
package-app.sh changes directory so it needs to make sure that all paths
are absolute and that the runfiles tree/manifest location is forwarded
to programs called by package-app.sh.
* Avoid file path too long errors
* Fix readlink -f on MacOS
* Document abspath
changelog_begin
changelog_end
Co-authored-by: Andreas Herrmann <andreas.herrmann@tweag.io>
Buildifier now comes with a handy attachment to catch single `\`
characters inside strings and replace them with `\\` if the escape
sequence is invalid. Skylark/Python will do this at runtime anyway; this
just makes it clearer what the actual behavior is.
I needed to change `\` characters at the end of lines to `\\` manually
in order to stop Buildifier from simply concatenating the lines
together. Everything else was automatic.
CHANGELOG_BEGIN
CHANGELOG_END
* support external anchors
changelog_begin
- `daml docs` now supports an `--input-anchor` argument specifying the
path to a database of external anchors
changelog_end
* Add daml-base-anchors.json to the damlc-dist target
* Fix ./fmt.sh check
We accidentally introduced hlint lints when we added the compatibility
workspace. The hlint code in ./fmt.sh correctly detects that there is
a hint but then exits with 0 since it uses the exit code from `echo`
rather than the one from `hlint`. The info that we printed with
`echo` didn’t actually make any sense so I added a new comment as to
why we run hlint here. This requires some setup changes so that the
compatibility workspace gets the same Haskell flags since otherwise
using the same hlint rules obviously does not make sense.
Fixes#5701
changelog_begin
changelog_end
* Update fmt.sh
Co-Authored-By: Samir Talwar <samir.talwar@digitalasset.com>
Co-authored-by: Samir Talwar <samir.talwar@digitalasset.com>
* Fix all DAML hoogle links.
This PR changes how the hoogle database is rendered in damldocs, so it has access to the mapping of anchors to URLs that is produced during rendering of rst docs. This way these will not get out of sync.
I also added an --output-anchor option in preparation for fixing external/cross-package references.
changelog_begin
changelog_end
* Update settings.json
undo accidental vscode settings change.
* Update README.md
* One module per page in stdlib docs.
changelog_begin
- [DAML Docs] The standard library docs have been split up per module.
changelog_end
* Adjust stdlib annotations
* Update compiler/damlc/daml-stdlib-src/DA/Generics.daml
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update compiler/damlc/base-rst-index-template.rst
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Move to daml/stdlib
* Update daml-doc tests
* Remove the Module prefix in the index/toctree
Co-authored-by: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
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
* Split up repl tests to make them faster
This PR splits up the tests into the tests for TLS and Auth and the
tests for the actual functionality.
The func tests use the repl as a library which allows them to be
significantly faster:
1. We only need to start the service process once.
2. We only need to initialize the package db once.
There is at least one other point that I did not address for now and
that is only loading the packages into the repl service once. While
loading them multiple times is a noop, it still has a performance
implication.
Sadly, this has turned out much more messy than I thought it would be
due to various issues with haskeline/repline/tasty/computers. The
details are in a comment in DA.Test.Repl.FuncTests.
changelog_begin
changelog_end
* Try to nuke cache on window selectively
* Enable cache again
* Extract package config type to a separate package.
changelog_begin
changelog_end
* update copyright headers
* run buildifier-fix
* fix src_strip_prefix
* Heres the file I accidentally deleted
* buildifier-fix again
As mentioned in the title, this is still very experimental and needs
more work before we want to advertise it. However, the code is in a
somewhat reasonable shape, there are tests and I think even in the
current state it is already useful. Also this PR is already getting
very large so I don’t want to hold off much longer before merging this.
It is included in the SDK but hidden from `damlc --help` and `daml
--help` until the most pressing issues are addressed (primarily around
making sure that it doesn’t just shut down if you have a type error
and better error messages in general).
changelog_begin
changelog_end
This PR fixes a whole bunch of bugs when using data-dependencies on a
package produced by damlc rather than the handcrafted simple-dalf.
The end result is that we are able to build a package with
`--target=1.6` and use it as a data-dependency from a package with
`-target=1.7`. While the test that I’ve added for this is not
cross-SDK it is arguably even trickier since we cannot rely on the
unit id of daml-stdlib changing the version in the unit id.
The changes all fall into one of the following two categories:
- Special handling for daml-prim and daml-stdlib to avoid collisions
with the one from the current SDK.
- Special treatment of stable packages to avoid generating new code
for those.
- Remove a couple of filters for daml-prim since we do need to include
daml-prim from a data-dependency if it is a different version.
This is definitely not perfect and there are a bunch of rather hacky
parts in here but it seems like a good intermediate step (and it has a
test :))
changelog_begin
changelog_end
* Move most of the remaining serializable types to stable LF packages
The only serializable types left in DAML stdlib after this PR are the
following:
- DA.Upgrade:MetaEquiv
- DA.Random:Minstd
- DA.Next.Set:Set
- DA.Next.Map:Map
- DA.Generics:MetaSel0
- DA.Generics:MetaData0
- DA.Generics:DecidedStrictness
- DA.Generics:SourceStrictness
- DA.Generics:SourceUnpackedness
- DA.Generics:Associativity
- DA.Generics:Infix0
- DA.Generics:Fixity
- DA.Generics:K1
- DA.Generics:Par1
- DA.Generics:U1
- DA.Internal.Prelude:Optional
Ignoring the Generics stuff which isn’t very urgent imho and the
Upgrade stuff which is probably going to change significantly anyway,
this leaves us with the weird Random module, the wrappers around
TextMap which will go away anyway and DA.Internal.Prelude:Optional
which shouldn’t exist in the first place (I’ll address that in a
separate PR).
CHANGELOG_BEGIN
- [DAML Compiler] Move more types from daml-stdlib to standalone LF
packages. The module names for the types have also changed
slightly. This only matters over the Ledger API when you specify the
module name explicitly. In DAML you should continue to use the
existing module names.
- The types from ``DA.Semigroup` are now in a separate package under
``DA.Semigroup.Types``
- The types from ``DA.Monoid` are now in a separate package under
``DA.Monoid.Types``
- The types from ``DA.Time` are now in a separate package under
``DA.Time.Types``
- The types from ``DA.Validation` are now in a separate package
under ``DA.Validation.Types``
- The types from ``DA.Logic` are now in a separate package under
``DA.Logic.Types``
- The types from `DA.Date` are now in a separate package under
`DA.Date.Types`.
- The `Down` type from `DA.Internal.Prelude` is now in a separate
package under `DA.Internal.Down`.
CHANGELOG_end
* Fix serializability of RelTime
* fix daml-docs
* Fix tests
This is a first step towards making sure that the package ids for
types defined in daml-prim and daml-stdlib don’t change. This PR
mostly adds all the necessary infrastructure for that and moves
GHC.Types and GHC.Prim to make sure it works.
Until data-dependencies are really solid and we have verified that we
no longer have performance issues with an increasing number of Haskell
packages, we still include the source files in daml-prim and then just
rewrite the references.
We will also need to add tests that these packages really have stable
ids but I’ll leave that for separate PRs since this doesn’t make that
much sense anyway until all of the types have moved to stable
packages.
CHANGELOG_BEGIN
- [DAML Compiler] The modules GHC.Prim and GHC.Types from daml-prim
have been moved to separate packages.
CHANGELOG_END
* Rename hie-core to ghcide
The name `hie-core` has caused a lot of confusion as to how we relate
to haskell-ide-engine so changing it should hopefully help with that.
I also think that ghcide is still a good name once we hopefully
integrate with haskell-ide-engine more closely.
The name ghcide seems to have a reasonable amount of support on
Twitter https://twitter.com/ndm_haskell/status/1170681262987710464
which is of course the only good way to come up with names.
* Add a readme that points people to the new directory.
* Fix bogus replacements
* Use a proper link
* links are hard
* language: check dflags for errors
We add a check when we build the dflags for cases that will lead to a
failed build and emmit a clearer error message. Currently this only
includes a check, to see whether the current installed unit id is also
imported as a package from the package database.
* exclude ghc-prim from check
* exclude code generation from dflag check
* add an internal option to turn dflags check off
This allows us to run "damlc build" in Bazel rules which is a
prerequisite for doing anything with DAML packages as they don’t work
with "damlc package".
* daml visualize with lsp
* Working command execution with ide
* Have to call visual now
* Split function
* Wrong constuctions of world or the module
* Working almost
* Have to gather all modules
* Now works end to end. Considers all the daml files in workspace
* removing unused code
* removing unused dependency
* Removing unused JS code and better error message
* Function re-arrange
* Removing us of heaad, instead handling error
* Format and rearranging
* Removing unused assignment
* Formating everything
* missed dependency
* Generating visual only for the file that is open
* Using modules from generated pkg, error messages
* Bringing back the commands
* Names and formating
* consitent error message
* Removing Just pattern match using _use now
* package
* Moving visual to a different module
* Function simple
* Removing Rule as it increases memeory consumption
* TODO LSP error
* White space
* Fmt things
* Handling if command was executed for a non daml files
* Better error message
* debugging
* Fix executeCommand
* Adding tests to execute command. Thanks moritz
* Unwanted lines
* Spaces and comment
* 3rd time ?
* Spaces are white
* assert equal instead of assert bool
* language: smoothing out the migration experience
Some improvements to make the migration process simpler when migrating
between packages with the same name, e.g. foo-1.0.0 -> foo-2.0.0. This
is the main use case.
This switches the creation of the archive in `daml build` from
`zip-archive` to `zip`. This has a few advantages:
1. It gets rid of lazy IO for reading all the interface and source
files. This avoids the high usage of file handles in `daml build`.
2. It seems to be a slight improvement in max memory usage and runtime
and a giant improvement in allocations (but I think the latter
probably comes primarily from the fact that the locations are moved to
the bzip C library). The improvement in max memory usage is less than
I expected so probably there is still something off somewhere.
For now, I only switched over `createArchive`. Archive reading is
still done using `zip-archive`. We might want to switch that over in a
separate PR.
