-
-
Notifications
You must be signed in to change notification settings - Fork 389
Leverage last apply-refact improvements in hlint plugin (include getParsedModuleWithComments in ghcide) #635
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
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