Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merge ghcide repository (replacing the submodule) #702

Merged
merged 730 commits into from
Dec 29, 2020
Merged

Merge ghcide repository (replacing the submodule) #702

merged 730 commits into from
Dec 29, 2020

Conversation

pepeiborra
Copy link
Collaborator

The merge was performed using the command:

 git merge ghcide/merge --allow-unrelated-histories

I have extended the Github CI to run the ghcide fmt, test and benchmark scripts.

The next step will be to transfer all the GitHub Issues

carlohamalainen and others added 30 commits May 4, 2020 10:02
* Add some troubleshooting notes.

* Update README with link to docker-ghcide-neovim instructions.

* Update README
- retrieve runtime version from ghc executable, not from pkg db (ghc-check 0.3.0.0)
- Do not error when unable to retrieve runtime version
* [#518] Build ghcide with GHC 8.10.1

Resolves #518

* Move CPP logic to the Compat module

* Revert changes to mkHieFile

* Add local fork of HieAst for 8.10.1

The fix for mkHieFile didn't make it into 8.10.1, so the override is still needed

* Ignore hlint in src-ghc810/HieAst.hs

* Whitelist CPP for Development.IDE.GHC.Orphans

* [#518] Build ghcide with GHC 8.10.1

Resolves #518

* Move CPP logic to the Compat module

* Revert changes to mkHieFile

* Add local fork of HieAst for 8.10.1

The fix for mkHieFile didn't make it into 8.10.1, so the override is still needed

* Ignore hlint in src-ghc810/HieAst.hs

* Whitelist CPP for Development.IDE.GHC.Orphans

* Plugin tests known broken in 8.10.1 (#556)

* Bump up ghc-check version

Co-authored-by: Pepe Iborra <[email protected]>

Co-authored-by: pepe iborra <[email protected]>
* Strip path information from diagnostic messages (#158)

* remove a distinction between 8.6 and 8.4 from an error message test
* Extend nix explanations in README

* Correct ghcide-nix url

Co-authored-by: Domen Kožar <[email protected]>

Co-authored-by: Domen Kožar <[email protected]>
Replace openDoc' with createDoc which sends out
workspace/didChangedWatchedFiles notifications
By collecting the fieldOcc names in the data con args
* Track dependencies when using qAddDependentFile

Closes #492

* Add test for qAddDependentFile

* Update test/exe/Main.hs

Co-authored-by: Moritz Kiefer <[email protected]>

* Update test/exe/Main.hs

Co-authored-by: Moritz Kiefer <[email protected]>

Co-authored-by: Moritz Kiefer <[email protected]>
* Testsuite: Only run with --test if necessary

* Add (failing) test to check GotoHover.hs file compiles

* Fix compilation of GotoHover.hs
* Rats: Fix space leak in withProgress

Eta-expanding the function means GHC no longer allocates a function
closure every time `withProgress` is called (which is a lot).

See: https://www.joachim-breitner.de/blog/763-Faster_Winter_5__Eta-Expanding_ReaderT

* Rats: Share computation of position mapping

Ensure that PositionMappings are shared between versions

There was a quadratic space leak as the tails of the position maps were
not shared with each other. Now the space usage is linear which is
produces more acceptable levels of residency after 3000 modifications.

* Rats: Eta-expand modification function

See: https://www.joachim-breitner.de/blog/763-Faster_Winter_5__Eta-Expanding_ReaderT

* Add a comment warning about eta-reducing

* Distinguish between a Delta and a Mapping in PositionMapping

A Delta is a change between two versions

A Mapping is a change from the current version to a specific older
version.

Fix hlint

Fix hlint
* Refactor rawDependencyInformation

There are two reasons why this patch is good:

1. We remove the special case of the initial module from the dependency
search. It is now treated uniformly like the rest of the modules.

2. rawDependencyInformation can now take a list of files and create
dependency information for all of them. This isn't currently used but on
my fork we have a rule which gets the dependency information for the
whole project in order to create a module graph.

It seemed simplest to upstream this part first, which is already a
strict improvement to make the overal patch easier to review.

* Make indentation not depend on identifier length

Co-authored-by: Moritz Kiefer <[email protected]>
Follow up from #557. We definitely want the progress state to be fully evaluated, so demand that with evaluating functions like evaluate and $!, rather than relying on the compiler to get it right. My guess is the `$!` is unnecessary now we have `evaluate`, but it's also not harmful, so belt and braces approach.
* Drop interface loading diagnostics

* No reason to skip the --test flag anymore
* Update to hie-bios 0.5.0

* Fix test-cases due to changes in the direct cradle

* Update test/exe/Main.hs comment

Co-authored-by: Moritz Kiefer <[email protected]>

Co-authored-by: Moritz Kiefer <[email protected]>
In 0.18.4 deprioritise was renamed reschedule, so follow the new name.
* Add kakoune installation instructions

* Add additional files to roots field
* Multi component support

In this commit we add support for loading multiple components into one
ghcide session.

The current behaviour is that each component is loaded lazily into the
session. When a file from an unrecognised component is loaded, the
cradle is consulted again to get a new set of options for the new
component. This will cause all the currently loaded files to be
reloaded into a new HscEnv which is shared by all the currently known
components. The result of this is that functions such as go-to
definition work between components if they have been loaded into the
same session but you have to open at least one file from each component
before it will work.

Only minimal changes are needed to the internals to ghcide to make the
file searching logic look in include directories for all currently
loaded components. The main changes are in exe/Main.hs which has been
heavily rewritten to avoid shake indirections. A global map is created
which maps a filepath to the HscEnv which should be used to compile it.
When a new component is created this map is completely refreshed so each
path maps to a new

Which paths belong to a componenent is determined by the targets listed
by the cradle. Therefore it is important that each cradle also lists all
the targets for the cradle. There are some other choices here as well
which are less accurate such as mapping via include directories  which
is the aproach that I implemented in haskell-ide-engine.

The commit has been tested so far with cabal and hadrian.

Also deleted the .ghci file which was causing errors during testing and
seemed broken anyway.

Co-authored-by: Alan Zimmerman <[email protected]>
Co-authored-by: fendor <[email protected]>

* Final tweaks?

* Fix 8.4 build

* Add multi-component test

* Fix hlint

* Add cabal to CI images

* Modify path

* Set PATH in the right place (hopefully)

* Always generate interface files and hie files

* Use correct DynFlags in mkImportDirs

You have to use the DynFlags for the file we are currently compiling to
get the right packages in the package db so that lookupPackage doesn't
always fail.

* Revert "Always generate interface files and hie files"

This reverts commit 820aa241890c4498c566e29b0823a803fb2fd297.

* remove traces

* Another test

* lint

* Unset env vars set my stack

* Fix extra-source-files

As usual, stack doesn’t understand Cabal properly and doesn’t seem to
like ** wildcards so I’ve enumerated it manually.

* Unset env locally

Co-authored-by: Alan Zimmerman <[email protected]>
Co-authored-by: fendor <[email protected]>
Co-authored-by: Moritz Kiefer <[email protected]>
* Prepare release of ghcide 0.2.0

* Fix year in copyright notices

* Credit chshersh for the 8.10 support
* Initial benchmark suite, reusing ideas from Neil's post

https://neilmitchell.blogspot.com/2020/05/fixing-space-leaks-in-ghcide.html

* Add an experiment for code actions without edit

* formatting

* fix code actions bench script

* error handling + options + how to run

* extract Positions and clean up imports

(Neil's review feedback)

* replace with Extra.duration

* allow ImplicitParams

* add bench to the cradle

* applied @mpickering review feedback

* clean up after benchmark

* remove TODO
* ShakeSession and shakeRunGently

Currently we start a new Shake session for every interaction with the Shake
database, including type checking, hovers, code actions, completions, etc.
Since only one Shake session can ever exist, we abort the active session if any
in order to execute the new command in a responsive manner.

This is suboptimal in many, many ways:

- A hover in module M aborts the typechecking of module M, only to start over!
- Read-only commands (hover, code action, completion) need to typecheck all the
  modules! (or rather, ask Shake to check that the typechecks are current)
- There is no way to run non-interfering commands concurrently

This is an experiment inspired by the 'ShakeQueue' of @mpickering, and
the follow-up discussion in mpickering/ghcide#7

We introduce the concept of the 'ShakeSession' as part of the IDE state.
The 'ShakeSession' is initialized by a call to 'shakeRun', and survives until
the next call to 'shakeRun'. It is important that the session is restarted as
soon as the filesystem changes, to ensure that the database is current.

The 'ShakeSession' enables a new command 'shakeRunGently', which appends work to
the existing 'ShakeSession'. This command can be called in parallel without any
restriction.

* Simplify by assuming there is always a ShakeSession

* Improved naming and docs

* Define runActionSync on top of shakeEnqueue

shakeRun is not correct as it never returns anymore

* Drive progress reporting from newSession

The previous approach reused the shakeProgress thread,  which doesn't work anymore as ShakeSession keeps the ShakeDatabase open until the next edit

* Deterministic progress messages in tests

Dropping the 0.1s sleep to ensure that progress messages during tests are
deterministic

* Make kick explicit

This is required for progress reporting to work, see notes in shakeRun

As to whether this is the right thing to do:

1. Less magic, more explicit
2. There's only 2 places where kick is actually used

* apply Neil's feedback

* avoid a deadlock when the enqueued action throws

* Simplify runAction + comments

* use a Barrier for clarity

A Barrier is a smaller abstraction than an MVar, and the next version of the extra package will come with a suitably small implementation:

ndmitchell/extra@98c2a83

* Log timings for code actions, hovers and completions

* Rename shakeRun to shakeRestart

The action returned by shakeRun now blocks until another call to shakeRun is made, which is a change in behaviour,. but all the current uses of shakeRun ignore this action.

Since the new behaviour is not useful, this change simplifies and updates the docs and name accordingly

* delete runActionSync as it's just runAction

* restart shake session on new component created

* requeue pending actions on session restart

* hlint

* Bumped the delay from 5 to 6

* Add a test for the non-lsp command line

* Update exe/Main.hs

Co-authored-by: Moritz Kiefer <[email protected]>
The benchmark script uses git worktree.
The upstream branch contains a ghcide submodule, which is not well supported by
worktree.
Once this PR has been merged and the upstream branch no longer contains a git
submodule, we can reenable it in the bench config
I missed these previously
These tests were underspecified and broke with the recent improvements to ghcide
diagnostics in haskell/ghcide#959 and included in this
merge.

Fixed by waiting specifically for the typecheck diagnostics and by being less
prescriptive in the number and order of code actions
The ghcide merge includes haskell/ghcide#948
which removes the language extension code actions

This makes the associated func-test fail, because the HLS plugin does not pass
the test (only the ghcide code action did). This is because the HLS plugin uses
commands, and the tests do not wait for the command edit to be applied.

The fix is to change the HLS plugin to return a code action with edits and no commands
With so many github actions (>60) we cannot afford to run on every push
Reminder that ghcide requires at least 2 capabilities
This is needed to build with Cabal v1 if ghc is built with
DYNAMIC_GHC_PROGRAMS=NO which is the case e.g. in Windows
```
Error: While constructing the build
plan, the following exceptions were
encountered:

In the dependencies
for shake-bench-0.1.0.0:
    Chart-diagrams needed, but the stack
                   configuration has no
                   specified version
                   (latest matching
                   version is 1.9.3)
    diagrams needed, but the stack
             configuration has no
             specified version  (latest
             matching version is 1.4)
    diagrams-svg needed, but the stack
                 configuration has no
                 specified version
                 (latest matching
                 version is 1.4.3)
needed since shake-bench is a build
target.

```
Error:

Error: While constructing the build
plan, the following exceptions were
encountered:

In the dependencies
for diagrams-postscript-1.4.1:
    hashable-1.3.0.0 from stack
                     configuration does
                     not
                     match >=1.1 && <1.3
                     (latest matching
                     version is 1.2.7.0)
    lens-4.18 from stack configuration
              does not
              match >=4.0 && <4.18
              (latest matching version
              is 4.17.1)
needed due to shake-bench-0.1.0.0
               -> diagrams-postscript-1.4.1
@pepeiborra
Copy link
Collaborator Author

@jneira this is going to be ready tonight. What's the status of the 8.10.3 release?

@pepeiborra
Copy link
Collaborator Author

@jneira this is ready to merge. Is there any reason not to do the 8.10.3 release from a branch?

@jneira
Copy link
Member

jneira commented Dec 29, 2020

mmm really no, I would prefer to release from master, to not have to keep the branch forever (if you want the exact history of the release, to bisect or whatever)
maybe it is possible without keeping the branch, my git foo is not great.

but I think the save of time for this "little maneavour" could worth it

@jneira
Copy link
Member

jneira commented Dec 29, 2020

we can try to make the release on top of this and fallback to the branch if there are problems

@pepeiborra
Copy link
Collaborator Author

@jneira it is standard practice to make point releases from release branches. I don't think that keeping the branch forever has any real downsides.

If the 8.10.3 release is made from master it will include the changes in this PR (a ghcide version bump) as well as all the other changes in master: the reworked Eval plugin, the new Class plugin, etc.

@pepeiborra pepeiborra merged commit 6a0e04e into master Dec 29, 2020
@mpickering
Copy link
Contributor

Is the plan to still keep ghcide usable as a light-weight tool? I still prefer using it over hls which is too bloated for my tastes.

@jneira
Copy link
Member

jneira commented Dec 29, 2020

Well, create release branches usually is related with a workflow where you are willing to create bug fix releases on them, and that is not our workflow for now.

And consistency matters, if you can trace all releases on master you will be surprised by that one.

But I am not strongly against, let's merge it and I will link in the release the branch used one

@jneira
Copy link
Member

jneira commented Dec 29, 2020

@mpickering you can now get a slimmed down version of hls, with no plugins or formatters:

cabal install -f-all-plugins -f-all-formatters

and you can add plugins one by one with

cabal install -f-all-plugins -f-all-formatters -f+eval ...

as described in #164 (comment)

pepeiborra added a commit to pepeiborra/ide that referenced this pull request Dec 29, 2020
pepeiborra added a commit to pepeiborra/ide that referenced this pull request Dec 29, 2020
@pepeiborra
Copy link
Collaborator Author

Is the plan to still keep ghcide usable as a light-weight tool? I still prefer using it over hls which is too bloated for my tastes.

ghcide stays around, yes. The goal here is to merge the git repos, not to retire ghcide.

But you know that HLS now has cabal flags to select which plugins get linked, so why not use that?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.