-
-
Notifications
You must be signed in to change notification settings - Fork 367
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
Leverage last apply-refact improvements in hlint plugin (include getParsedModuleWithComments in ghcide) #635
Conversation
I've detected that the ghc-8.10 path that uses the new |
b4c8d6a
to
675ec23
Compare
675ec23
to
9e30310
Compare
rebased over the tests recently added in master |
a671a0e
to
18d20e0
Compare
Ok, tests are passing for ghc <= 8.8 We have two options:
|
b616aa5
to
1c56e0e
Compare
As expected, the ghc-8.10 code path does not preserve normal comments 😟
maybe any ghc-exactprint expert could help me to find the way to preserve them? 🙏 |
ok, i think i know the cause of mising comments:
links: haskell/ghcide#350 (comment), and mpickering/ghcide#22 (comment), ghc wiki about https://gitlab.haskell.org/ghc/ghc/-/wikis/api-annotations
haskell-language-server/plugins/hls-hlint-plugin/src/Ide/Plugin/Hlint.hs Lines 342 to 356 in 9ac127e
So the plan would be
|
That seems very sensible. Have two graph nodes which are the parsed module with Opt_KeepRawTokenStream and with Opt_Haddock as separate entities with distinct names. Then you have a single "I don't care" node which is haddock if you have it, otherwise not.
I think this is a matter of heuristics. Is the case you are worried about having CPP? I would play around and see what works best, but I think its inevitable that you aren't going to be able to do all cases every time. |
1c56e0e
to
1cb06ed
Compare
* applyRefactoring accepts ghc extensions to parse the file * new applyRefactoring' function accepts the parsed module Thanks @zliu41!
1cb06ed
to
8a7f68c
Compare
A possible heuristic could be take the smallest source span between:
Unless a refactoring could cross those boundaries... In any case i would try to do it in a new pr. |
Ok, tests now are green so the pr could be reviewed |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The ghcide changes lgtm
a10f03e
to
bb41ae6
Compare
bb41ae6
to
decf082
Compare
I am gonna merge this as is, if nobody disagree. |
The build is failing with
ghc was already installed in other location:
So i think ghc was installed using ppa:hvr and the haskell-setup is not longer using the runtime installation using ghcup. Weird thing, i wonder if the session checker should be able to use the libdir returned by the cradle to avoid this kind of errors I am gonna update the hackage index in cabal project, to invalidate the cache. |
The cache mechanism has ignored the change in the cabal.project, it is using the same cache key:
But afaiu the cache had to be invalidated due to haskell-language-server/.github/workflows/test.yml Lines 74 to 86 in a4627e5
I think the restore key Add the ghc libdir in the cache could be a way to fix it but i am not sure if it is a good idea. |
Adding the ghc lib dir to the cache key does sound like a good idea |
well it only will be an issue when using a new ghc version and I think the right solution could be
I want to remove the hardcoded libdir from ghc-exactprint. will do in a new pr if needed |
This pr take advantage of recent improvements in apply-refact, courtesy of @zliu41:
We should use a release version of
apply-refact
, if possible