* 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
In moving from v. 0.15 to 0.16, haskell-lsp changed the type of the
value which ended up being passed to `pretty` from `Maybe Text` to
`Maybe LSP.NumberOrString`, thereby breaking the line of code which is
removed in this commit.
After discussion with @ndmitchell, it was observed that this code was
never useful, and fixing it was not worth the trouble.
* Put information about the compiler pass in the _source field of Diagnostic
It's useful when looking at the hie-core command-line output to see where
a problem is coming from.
* include test code in hie-core's own cradle
* #2326, GHC 8.4 compatibility
* Fix up CI
* Add a Shake lower bound
* Upgrade to a hie-bios which is GHC 8.4 compatible
* Add a GHC 8.4 stack
* Fix HLint again
* language: compile everything in the source directory
This removes the need to specify a 'main'. Instead we 'source' in
daml.yaml should point to the source root directory.
Noticed this while trying to debug the segfaults.
I don’t have a concrete case where this causes issues (usually we only
call this once on startup so leaks are not an issue) but we might as
well do it properly.
The hie-core tests are flaky in stack. They can fail with the following
error message
```
hie-core: panic! (the 'impossible' happened)\n (GHC version 8.6.5 for x86_64-unknown-linux):
Dynamic linker not initialised
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
Explicitly initializing the dynamic linker at session startup should
avoid this issue.
* Only report progress when client supports it
This fixes an issue that some people encountered when running hie-core
in Emacs with a version of haskell-lsp that does not understand
progress events.
* Fix tests
* More test fixes
Otherwise, we can end up retaining references to the old map which
prevent it from being garbage collected.
On a simple testcase that repeatedly opens and closes a module, this
seems to make memory usage constant whereas it was increasing
each time before.
* Upgrade haskell-lsp and lsp-test
There have been some fixes upstream that should hopefully mean that we
no longer need to mark the lsp-tests as flaky on Windows. I am having
trouble reproducing the flakiness locally, so let’s see what happens
on CI.
* Also bump stack.yaml
Comparing FilePaths is really slow so by mapping them to Ints, we can
speed up dependency chasing significantly.
We might want to switch to doing some kind of global hash consing of
file paths at the Shake level but for now, this seems like a nice
improvement while not being too invasive.
This is roughly an ~8s speedup on my testcase.
This PR moves as much work as possible to GetLocatedImports which
contracry to GetDependencyInformation is shared between rules.
It’s still slower than it should be and somewhat messy but at least
it’s slightly faster and imho cleaner than before.
* Make --shake-profiling use the directory based profiling
The single-file based profiling is rather useless in the IDE and I
always found myself having to modify the source to set `profileDir` so
this PR switches the CLI option to control that instead.
* Add --shake-profiling to damlc ide
This is in preparation for #2326 as well as for splitting hie-core
into a separate repo. Given that, it explicitely avoids using our
dev-env.
We do need to install a few system packages, so for now this uses the
hosted builder so we can do this. Another option would be to just add
those to our builders. I don’t really have a preference either
way. The builds are < 5 minutes so I don’t expect issues from using
the hosted builders.
Speed up file modification checks
Summary: `getModificationTime` from the `directory` package is really
slow. The `unix` package is faster but still slow. This PR brings the
time spent checking file modifications (which is required on every
change) from ~0.5s to ~0.15s.
* language: a shake rule to get interface/hie files
This adds a shake rule to get module interfaces and hie files. This
gives more control on when to build them and also an opportunity to
change the package name after typechecking. This is used in the next
PR to add package hashes to the package name in the interface files.
* generate hie files only on demand
* Improve debugging output
Displaying the exception makes it easier to figure out what is going
wrong.
I’ve also added a HasCallStack constraint to `locateRunfiles` since it
looked like that was failing. Turned out to be a call to `create` that
didn’t go via `locateRunfiles` but I think it’s useful either way.
Should be more useful with https://github.com/tweag/rules_haskell/pull/1007
* Update compiler/hie-core/src/Development/IDE/Core/Shake.hs
Co-Authored-By: Andreas Herrmann <42969706+aherrmann-da@users.noreply.github.com>
* Upgrade ghc-lib
* Patch bazel_tools : hazel-include-paths patch, no-isystem patch.
* Provide "haskell_c2hs" for package name to cabal_haskell_package
* Package name haskell_c2hs => c2hs.
* Switch to less hacky patch for include dirs
* Support depending on potentially stale values in damlc
For now, this is opt-in and only enabled for the scenario service.
Locations should be properly mapped so if lines are inserted above a
scenario, the scenario link will move down.
* hie-core/test: Dedicated test suite for hie-core
* Apply hlint suggestion
Use System.Environment.Blank's setEnv which has a non-overwrite mode
that implements precisely what we were doing with more code before.
* buildifier fixes
* hie-core-exe works on Windows now - ghc-paths was fixed
This is a refactoring-only PR in preparation for supporting stale
values in damlc so we can still produce some results if a rule fails
to produce a value but has a stale value stored.
Some `Development.IDE.*` modules were imported qualified as either `Compile`
or `CompilerService`. These names are at least odd and maybe also
misleading. Since there's no actual need to import them qualified, let's
just import them not qualified.
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.
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.
