-
-
Notifications
You must be signed in to change notification settings - Fork 398
fix: add context code action with trailing comment #4649
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
Conversation
24493db
to
bf75a82
Compare
The current code was tested with GHC 9.12 and does fix the broken generated code. However it can:
The difficulty comes from the way comments are stored in the AST: they are not stored "inline", interleaved with the ast nodes. Instead, they are stored in a list of comment attached to an ast node and each comment is localised with it absolute position in the stream as well as the position of the latest taken (in order to introduce whitespaces). Consider the following example: bar ::
-- BEFORE
{- yoto -} (Monad m {- yiti -}){- yutu -} => {- yete -} -- Trailing
-- After
m ()
In order to insert a value after Note that I'm discovering the annotation API right now and maybe there is a solution for that. Especially, there is https://hackage-content.haskell.org/package/ghc-9.8.1/docs/GHC-Parser-Annotation.html#t:AnchorOperation |
2c1799f
to
7b223aa
Compare
I've spent a few hours trying to understand the exact-print semantic in order to correctly handle all cases and I admit that I'm failing here. I'm not sure that exact-print is working as expected, or not or what I'm supposed to do next. What should we do now? @fendor, you did accept the MR, thank you. Should we merge considering that:
What is better, a code action which does not work at all, or a code action which works, but in some context, can (silently) move comments ? Note: I think I have fixed the CI issues related to formatting, however some failures may not be related to this MR. |
The bench failures seem to be caused by this PR:
Yes, I think this PR is a net-improvement over the status quo |
7b223aa
to
92158db
Compare
CircleCI complains about a missing warning.
and it complains that This is for GHC 9.6.6. |
This closes #4648. When adding constraint to a context which is followed by a comment, such as: ``` foo :: (Monad m) => -- | This is a comment m () ``` The comment annotation is anchored to the previous token, which is `=>` in this context. If we add a new constraint in the context, the newly generated content goes beyond the anchor and, depending on GHC version, or ghc-exactprint (the reason is not fully understood), the comment is printed BEFORE the new constraint, leading to invalid syntax, such as `(Monad m -- | This is a comment , Applicative m =>)` This commit moves all the comment of the block at the end of the block using the `followingComments` of `EpAnnComments`. It seems super adhoc, but actually, consider the following example: ```haskell bar :: -- BEFORE {- yoto -} (Monad m {- yiti -}){- yutu -} => {- yete -} -- Trailing -- After m () ``` Comment `BEFORE` and `yoto` are attached to the previous block. Comment `yiti` is attached to `Monad m`. The comments `yiti`, `yutu`, `yete`, `Trailing` and `After` are all attached to this block and will hence be moved after the block. However this is not an easy task, all the associated comments should be moved by the relevant offset. TODO: do that instead.
92158db
to
80be44c
Compare
I do really apologize for the unnecessary ping pong. I first saw the warning about formatting (e.g. my Anyway, thank you for the review, I pressed the merge button. |
For now it is just a repro for #4648
Tested with ghc 9.12.2, it seems to fail as expected:
(see how
Eq b)
is introduced inside the haddock commentThis is the first argument
.I'm pushing the branch for reference and to test with other GHC version (I'm too lazy to build that locally, cabal cache was hot for ghc 9.12.2).