-
-
Notifications
You must be signed in to change notification settings - Fork 389
Insert pragmas after shebang or to existing pragma list #1731
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
Insert pragmas after shebang or to existing pragma list #1731
Conversation
I commented too late 😟 : #1726 (comment)
Tests are definitely needed, to ensure there is no regression and to see examples about how it works |
If we were to enable the option to insert at the top of the file, I suppose we would just have #555 again so perhaps I should just close this PR. I suspected this may be the case, hence I waited before writing the tests 😔 |
I would say adding an option is definitely not ideal. Perhaps we could fix the real issue by finding the first non-empty line after a possible shebang, using file contents rather than parsed module. |
No an expert in the ghc parse ast but i think they would be present as annotations. We have to use the version of the parsed module that includes such annotations (and no the default one) @emilypi solution could be a little bit more adhoc but could work too. In fact i think #1340 tried to do it but was superseded by #1417 which established the actual behaviour. //cc @berberman |
#1340 added a regression test over the shebang case: haskell-language-server/test/functional/FunctionalCodeAction.hs Lines 558 to 588 in c117657
And this pr didnt break it (and should afaiu), |
This reverts commit 8cebdd5.
Perhaps I missed some discussion, but the issue was that we were inserting pragmas after module haddock, right? So could we just extend the property to be "insert just before the first declaration, import, module header, or haddock comment"? |
Is it necessary to insert before haddock comments or could we just insert before any comments? I've just pushed a commit to do the latter but I can change it to specifically haddock comments if necessary. |
before any comments sound good to me too 🤔 |
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.
Looks great, thanks!
Let me be annoying, what about this?
I think it's pretty common for people to put comments inside their pragma blocks, which will result in slightly weird behaviour. But nobody puts haddock comments in their pragma blocks! |
Can we also consider inserting below copyright comments? E.g.
|
Personally, I think the property should be as below, even if this doesn't deal properly with copyright headers when there is no existing pragmas:
|
Thanks, I hadn't thought about this.
This should now be the behaviour of the code. |
Can we reach this by merely looking at file contents instead of parsed module? If there is an existing pragma, we insert the new one below it; otherwise we insert the new one after shebang meanwhile before the first non-empty line. Not sure if this will work or I missed something, but I believe getting rid of parsed module would avoid mysterious CPP macro in test. |
I can't see any immediate reason why using file contents wouldn't work. What would be the performance difference with this solution? I might be able to refactor it to take this approach at some point, but I have exams at the moment 😔. In the meantime, since we don't guarantee any order of inserting pragmas, are there any practical issues with the current solution? sorry for the late response |
No, I think it's good enough :) I suggest not using parsed module because missing language extensions like TypeApplications will result in a parse error, rather than a typecheck error - in such case our strategy will no loger work, and the pragma will be inserted to the top of file. |
Ugh, that is a bit annoying. Maybe we should add a paragraph to the known limitations section about that, since I bet people will hit it (I think inserting But yeah, I don't think fixing it should block this PR. |
…ne/haskell-language-server into pragma-insert-location-option
I decided it'd be best to just fix this issue now so I've pushed a new commit which hopefully should. |
Thanks again! |
Fix: #1726
Pragmas are now inserted before comments.
Updated the behaviour to insert directly after existing pragmas, else directly after shebangs, else at the top of the file.
Refactored to use the file contents rather than a parsed module so that missing pragmas, which cause parse errors, are still inserted into the correct position.