-
-
Notifications
You must be signed in to change notification settings - Fork 391
Refactor pragmas plugin #1417
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
Refactor pragmas plugin #1417
Conversation
I think your nix shell is somewhat outdated, and uses old package... the message says it still uses |
Oh! I see. I entered the nix-shell before pulling your fix. Now it works |
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 good to me, thanks!
Tests are failing due to the order of pragmas:
|
Perhaps the order is unstable? I copied
|
No it's stable. I executed the code action manually on my machine (GHC 8.10.3): TypeApplications was always inserted above ScopedTypeVariables.
This error was reported in GHC 8.8.4, and 8.6.5 (maybe all under 8.10), so the order likely depend on the version of GHC... |
ab99b2e
to
88f01d3
Compare
Hi, i've seen some changes here similar to #1340, concretely the move of |
This PR should fix #555, but I didn't add the corresponding test, which will be finished by #1340 instead. So @ishmum123 should rebase #1340 on this, if we want to merge #1340. |
-- TODO: Why CPP??? | ||
#if __GLASGOW_HASKELL__ < 810 | ||
[ "{-# LANGUAGE ScopedTypeVariables #-}" | ||
, "{-# LANGUAGE TypeApplications #-}" | ||
#else | ||
[ "{-# LANGUAGE TypeApplications #-}" | ||
, "{-# LANGUAGE ScopedTypeVariables #-}" | ||
#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.
Tests can pass now by adding this, though it's not clear to me...
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.
Well, we could force a ordering (alphabetical? i would say pre 8.10 is the right one) but not sure if it worths tbh
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.
In this test case, getParsedModule
should return Nothing
, because the module will result in parse error without enabling TypeApplications. So the insert line is always 0
, which means TypeApplications will be inserted to the top (and inserting after the shebang will not work). But in tests under GHC 8.10, TypeApplications is inserted under ScopedTypeVariables, so It seems that in pre 8.10 cases GetParsedModule
rule does not return Nothing
.
Even if GHC parser returns POk
instead of PFailed
for non-fatal errors like this one since 8.10, parseFileContents
should fail immediately when we encounter errors (if I understand correctly), so it's weird that GetParsedModule rule does not return Nothing
...
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.
Weird indeed, i think #1340 failed to pass tests for the same reason
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.
Hmm actually #1340 failed to pass is expected. Test added by #1340 uses TypeApplications as the test object. As mentioned above, missing TypeApplications will result in parse error, so "after shebang" won't work in this case. #1340 should change another pragma to test and mark this case as an expected failure.
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.
oh, i see thanks for the insight
what would be the solution in that case (shebang + needed TypeApplications)?
The plugin should suggest add it (to fix the parse error itself) but it would add it in the incorrect position (as we dont have the parsed module)
Maybe that combination is improbable though...
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.
We could use file contents as the fallback. But imo what's really rare is shebang -- inserting pragmas shouldn't have been depended on parsed module...
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.
@berberman what would you suggest for #1340 ? Should I expect a different Pragma or remove dependency upon the parsed module?
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.
@ishmum123 Please change another pragma to be tested with shebang.
380a65a
to
7643361
Compare
7643361
to
8622380
Compare
All tests are finished. The return value of GHC 8.10.4
GHC 8.8.4
GHC 8.6.5
|
8622380
to
eebf6b6
Compare
@beberman many thanks, great work and lot of useful info in the way |
Closes #1413
BTW I still couldn't run pre-commit hook successfully...pre-commit hook purposed in #1384 enforced formatting files edited in this PR, a good sign!