There is lots of room for improvements here but I think this is a good
first step. The 3 main things that could be improved imho are:
- Rewrite source locations to point to the original file rather than
the generated module
- Provide some way to declare things like imports or more general,
setup code that is added to the generated module.
- Prettier/more helpful output during a run, e.g., print the list of
successful tests.
* internal name
* Adding internal choice name
* correct but ugly
* no more awkard underscore for create and archive
* not more underscores
* creating archive is not necessary
* simplify
* Removing duplicate
* simplified code
* Using cons intead of ++
* not needed parans
* Formatting
* Use type information in function docs
* idpToText -> packRdrName
* Use tycon to get superclasses
* Make anchors from tycons
* Generate all type anchors with tyConAnchor
* Type information is everywhere
* Render links.
* s/missing/available/
* Update golden tests
* Hlint / refactor
* Clean up import list
* Banish evil
* Catch lint
* Use mapMaybe
* Use list comprehensions instead
* packModule -> getModulename, dc_mod -> dc_modname
* Deal with tuple constructors properly
* Update the test case
* Better docs in Rst renderer
* Add test that uses type sig links
* Update release notes
* Get draft rule in
* Hlint is now firing
* First hlint unit test
* This gets hlint working in the ide
* Select hlint.yaml contextually. Wip
* Fix prod path
* Switch between prod and test versions of hlint.yaml
* Format
* Ignore hlint hints in the language tests
* Add some debugging stuff. LSP stress test is broken
* Update compiler/damlc/daml-ide-core/src/Development/IDE/Core/Rules/Daml.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Tidy up some details
* Simplify settings (remove unused parseFlags)
* Fix LSP stress tests
* ./fmt.sh
* Collapse to one hlint.yaml, provide options
* Fix location of hlint runfiles
* Disable hlint by default; enable for shake-ide tests
* lint (ironic)
* Remove filtering of lints from integration test
* ./fmt.sh
* Respect the flag
* Silence opininated lint
* Update compiler/damlc/daml-opts/daml-opts-types/DA/Daml/Options/Types.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* Update compiler/damlc/lib/DA/Cli/Damlc.hs
Co-Authored-By: Moritz Kiefer <moritz.kiefer@purelyfunctional.org>
* I really did mean optHlintEnable here
* Move hlint enabled check to ofInterest like shouldRunScenarios
* Rename variable
* Cache settings
* Missed a merge conflict
* lift liftIO
* Remove the hlint-testing POC
* use useNoFile_
we make sure the right things are qualified and the right things are not
qualified in generated code. we also add GHC.Types always to the imports
because it's potentially used by native types such as 'Int' and we don't
import Prelude.
This adds two compiler options ifaceDir and isGenerated to the compiler
options. These will be needed to write generated interface files to the
right directory and treat generated source files special when generating
interface files.
There were two issues:
1. VSCode changed their packaging so we now need to depend on
`@types/vscode`. This broke `yarn run compile`. I have no idea why
this did not cause an error in the Bazel build. Presumably the giant
tsconfig that it generates was doing something different.
2. We excluded src/webview.js in .vscodeignore which means that it was
not included in `vsce package` and thereby also not in the extension
included in the marketplace.
For now, we only show a “Progressing” message and a done/todo
indicator. We could eventually try to come up with something better
but I’m not quite sure what that would be since we try a lot of things
in parallel and the triggering request isn’t particularly
useful (users won’t know what a codelens request is and why they have
to wait for it).
Note that VSCode seems to have some delay in updating these
notifications so you only see the done/todo reports if it is
processing for a while.
* Run typechecker in damldocs (but don't use result yet)
* Add Modulename to TypeApp constructor.
* Add md_name where appropriate.
* Thread a DocCtx through each doc extractor.
* Move template set and choices map into docctx
* Use Typename for template set and choice map
* Make Anchor a newtype and move it to Types
* Make Modulename in TypeApp an Anchor instead.
* Remove import of hidden module.
* Qualify that which doth need be qualified
* Update tests
* Build stdlib in such a way that it passes typechecking.
* Update release notes.
* Remove MOVE Prelude directives in daml-prim.
* Use optional in damldoc options
* Update function hashes
* Compile base packages to json first
* Proof of concept : hlint/daml
* Copyright check is naieve
* Missing copyright
* Move hlint-testing out of compiler
fmt.sh tries to invoke hlint on the compiler directory. This then fails like,
```
2019-07-08T21:04:48.8037836Z $ hlint --git -j4
2019-07-08T21:04:48.9217137Z Couldn't find file: hlint-testing/data/HLint_QuickCheck.hs
2019-07-08T21:04:48.9277694Z UNEXPECTED HLINT FAILURE: The Bazel rules should have spotted this, please raise a GitHub issue
```
* Reformat
* This linting and formatting and so on is getting tiresome...
* Replace links with real files
* Strip the data directory
* Move files back under compiler/hlint-testing
* Copyright report_template.html so that format checks pass
* Calculate a hlint data directory path
* Whitespace and delete unneccessary file
* The format script uses this
* Use locateRunfiles
* Tweak record initialization formatting
* Reformat build file
Previously, we unconditionally assumed that GHC will only use those on
Enum-like types, i.e., types with only nullary constructors. This
assumption turns out to be incorrect so this PR introduces additional
checks.
* Move files in daml-foundations/daml-ghc to compiler/damlc
There is also a bit of refactoring going on to actually split things
apart into sensible targets. What is still missing is a cleanup of the
module hierarchy and a cleanup of the test targets but I’ll leave
those for separate PRs.
As a nice bonus, this also reduces dependencies between targets so it
will speed up compiles.
* Update .hie-bios
Previously we rewrote references to `PRSelf` to `PRImport` references
every time we call `initWorld`. However, we call `initWorld` quite
often (e.g. every time we run a scenario) while the packages that need
to be rewritten stay constant. Since rewriting the package references
requires traversing the whole package, this can be quite expensive.
This PR moves the rewriting of package references out of `initWorld`
and caches it as part of `GeneratePackageMap`.
On a large project where I tested this, this caused a drop in the
runtime of `daml test` from 250s to 200s. In the IDE this can also
make a pretty big difference since we call this everytime we run a
scenario which we do on every file change.
* check that submitter is in maintainers when looking up keys
Fixes#1866. Note that this limitation applies both for `lookupByKey`
and `fetchByKey` -- anything involving retrieving a key is affected.
* add UNTIL-LF to run tests up to a certain version of DAML-LF
* name targets for DAML tests better
* add notes about DAML-LF changes
* commit Test.daml with DAML-LF 1.5 rather than compiling it on the fly
* add scenario tests for #1866
* add warnings about future key behavior in docs
* use flag rather than version when executing
Most of them were caused by off-by-one errors in goto definition.
There was also one test that was marked as an expected failure but the
actual bug has been fixed for some time and the only reason it was
failing is that the error message was different than the test
expected.
I’ve also renamed daml-ghc-shake-test-ci to damlc-shake-tests which is
something that I might actually be able to remember :)
Previously, we only checked two diagnostics messages. However, the
second diagnostics messages does not actually need to correspond to
the latest change but can just be a message that has been in the queue
from one of the 1000 changes before. Now we make sure to actually
check all (or at least every second) diagnostic.
This was technically also an issue before but since we only emitted
diagnostics when they changed and we alternate between two states it
worked fine. The way we implement debouncing means that we can now
also end up emitting two consecutive diagnostics changes for the same
set of diagnostics which made this test flaky.
Given that we already made the max message size configurable it only
seems reasonable to also make the timeout configurable and on very
large projects, we do sometimes hit this.
Previously, we emitted diagnostics notifications as soon as we got
them. This resulted in a lot of flickering due to diagnostics getting
cleared briefly when typing only to immediately reappear.
Now, we buffer them for 0.1s so that a new event restoring the
same diagnostics for a slightly modified file will overwrite the
initial clear of diagnostics for the new document version.
* Split off addRelativeImport from modifying the session
* Switch located imports to adding their own relative imports
* Delete the unused getGhcDynFlags
* Make runGhcEnv no longer need to consult import paths
* Call runGhcEnv directly
* Move getSrcSpanInfos out to Spans
* Remove a redundant import
* Make findImports in Either rather than ExceptT
* Move getImports over to the right place
* Switch to liftEither
* Get rid of orphan usage in Convert
* Get rid of orphan usage in AtPoint
* Delete one entirely unused orphan
* Remove a comment that is no longer true
