-
-
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
Remove exactprint dependencies from ghcide by introducing hls-refactor-plugin. #3091
Conversation
3331644
to
bd09b59
Compare
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.
Blind approve
bd09b59
to
3a0fbf8
Compare
3a0fbf8
to
5155661
Compare
@pepeiborra you might want to look the changes to |
5155661
to
bac9fec
Compare
Also the async tests now use code lenses instead of code actions, I believe this still preserves the expected test behavior, is that correct @pepeiborra? |
a8c1078
to
65d642a
Compare
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.
Awesome, I think this split is great! Will make it much easier to get initial support for new GHC Versions!
I have some minor nitpicks, thank you very much for your work!
-- li (pre $ text (exactPrint a0)), | ||
-- li (showAstDataHtml' a0), | ||
-- li (nested "Raw" $ pre $ showAstData NoBlankSrcSpan NoBlankEpAnnotations a0) |
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.
Why are these still comments? Should probably be removed, if we are not going to use them anymore?
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.
I want to get @pepeiborra's opinion on this first.
-- #if MIN_VERSION_ghc(9,2,1) | ||
|
||
-- #else |
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.
Remove?
-- #if MIN_VERSION_ghc(9,2,0) | ||
-- , exactPrint x | ||
-- #endif |
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.
remove as well?
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.
Tactics stuff lgtm
65d642a
to
76c92a3
Compare
6076ba9
to
929bd97
Compare
@pepeiborra I've also replaced code actions in the benchmarks with code lenses. This is unfortunate, but we should fix this in the future by benchmarking the entire IDE with plugins included instead of just |
I'll take a proper look over the weekend |
I don't love the idea of dynamically looking up another plugin just in order to get access to some helper code. I think that could do with some clear documentation and a big warning saying not to use it unless you really really have to. I'm not sure what the "right" solution is: probably moving the completions logic to a plugin and pulling out a common dependency? |
929bd97
to
2a3c304
Compare
4fcddfc
to
a2769a9
Compare
All the plugins that use the |
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.
look the changes to showAstData in
ghcide/src/Development/IDE/GHC/Dump.hs
I would have extracted this function and traceAst
too
Also the async tests now use code lenses instead of code actions, I believe this still preserves the expected test behavior
Yes!
I've also replaced code actions in the benchmarks with code lenses. This is unfortunate, but we should fix this in the future by benchmarking the entire IDE with plugins included instead of just ghcide
We should probably benchmark every plugin in isolation.
If we are serious about composing plugins together, this is behaviour we probably want to support, so that plugins can pass off tasks to each other in such cases.
I agree
Also there's still an inverse dependency, in that extendImportCommandId is still defined in ghcide. So this won't work as a way of composing plugins together unless you have a central registry of the possible command ids to look for.
This is only because completions are still inside ghcide. Once they are extracted to their own plugin, the dependency will be hls-completions
-> hls-refactor
. But this would mean hls-completions
cannot be built until hls-refactor
has been ported, so we would probably want to put the command id inside a new package hls-refactor-command-ids
. Which can be done right now. @michaelpj what do you think?
All the plugins that use the GetAnnotatedParsedSource rule now have to link it in via pluginRules to ensure they have access to it even if hls-refactor-plugin is disabled.
Yeah, this makes sense, just keep in mind that his-graph
only deduplicates rules, not rules actions (created with action :: Action a -> Rules a
).
mkAdditionalEditsCommand pId edits = | ||
mkLspCommand pId (CommandId extendImportCommandId) "extend import" (Just [toJSON edits]) | ||
mkAdditionalEditsCommand :: Maybe PluginId -> ExtendImport -> Maybe Command | ||
mkAdditionalEditsCommand (Just pId) edits = Just $ mkLspCommand pId (CommandId extendImportCommandId) "extend import" (Just [toJSON edits]) |
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.
Would it make sense to introduce an abstraction for this dynamic lookup now?
Something like:
genLspCommand :: IdePlugins a -> CommandId -> Maybe (Text -> ... -> Command)
genLspCommand = fmap (mkLspCommand ...) (lookupPluginId ...)
plugins/hls-refactor-plugin/src/Development/IDE/GHC/ExactPrint.hs
Outdated
Show resolved
Hide resolved
plugins/hls-refactor-plugin/src/Development/IDE/Plugin/CodeAction.hs
Outdated
Show resolved
Hide resolved
extendImportHandler ideState edit@ExtendImport {..} = do | ||
res <- liftIO $ runMaybeT $ extendImportHandler' ideState edit | ||
whenJust res $ \(nfp, wedit@WorkspaceEdit {_changes}) -> do | ||
let (_, List (head -> TextEdit {_range})) = fromJust $ _changes >>= listToMaybe . Map.toList |
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.
It would be good to copy over the hlint config from ghcide
Well, I think we should think about what a world where we do this more often looks like. I think we'd have to have a package where all the command IDs for all plugins are defined. That wouldn't be so crazy: that's the "interface definition" for a plugin in this case, and having a separate interface definition which calling modules depend on isn't that unusual. I think I'd rather have one such package than one per plugin, though... It's still quite ugly in that it means that we end up with a bit of logical coupling between all our plugins in this location. I don't have any better ideas, though. I would be happiest if we could just avoid doing it 😅 So I would prefer |
4d044c7
to
7ad882a
Compare
I will do this in another MR. I think this one is ready to merge. |
c2fb1b1
to
4223717
Compare
431e3e8
to
628a866
Compare
…r-plugin. All code actions have been moved to hls-refactor-plugin Mostly straightforward, only slight complication was that completion auto imports depends on exactprint, but I didn't want to remove all completion logic from ghcide just for this. Instead, I added logic to dynamically lookup the plugin that provides the extend import command, so that auto imports work as expected when you have hls-refactor-plugin enabled. Move lookupPluginId out of loop Replace code actions with lenses in benchmarks Allow plugins to use GetAnnotatedParsedSource by linking it in when depended on Move lookupPluginId to IdePlugins Add default extensions Move traceAst
30679f3
to
455766d
Compare
455766d
to
291416b
Compare
291416b
to
36d66ec
Compare
All code actions have been moved to hls-refactor-plugin
Mostly straightforward, only slight complication was that completion auto imports
depends on exactprint, but I didn't want to remove all completion logic from ghcide
just for this.
Instead, I added logic to dynamically lookup the plugin that provides
the extend import command, so that auto imports work as expected when you have
hls-refactor-plugin enabled.