Skip to content

Add fix for placement after multiline pragma #2401

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

Closed
wants to merge 1 commit into from

Conversation

nini-faroux
Copy link
Contributor

@nini-faroux nini-faroux commented Nov 25, 2021

This is in reference to the issue mentioned in #2392 pr.

It adds a fix for the case where LANGUAGE or OPTIONS_GHC pragmas span multiple lines - where previously it was assuming that they were all single line pragmas.

@pepeiborra
Copy link
Collaborator

Is this related to #2364 ?

@jneira
Copy link
Member

jneira commented Nov 25, 2021

It seems to me that #2364 rewrites the entire logic so not sure how this fix would fit. Regression tests are useful for sure, thanks!

@nini-faroux
Copy link
Contributor Author

No it doesn't fix that issue, but it was an issue with the previous solutions from the start it seems, where it was always assumed that the OPTIONS_GHC and LANGUAGE pragmas were just one line.

One thing I was wondering about #2364 that I mentioned in the other pr, is whether it makes sense for the user to add an OPTIONS_GHC pragma or shebang later in the file? As in the user guide the OPTIONS_GHC pragma is considered a file header pragma.

https://downloads.haskell.org/~ghc/7.0.3/docs/html/users_guide/pragmas.html

So even if it compiles, would it be considered a user error to place one lower in the file, or is it common for people to do that? If we can assume that the Shebangs, LANGUAGE and OPTIONS_GHC should all be at the top of the file, we could keep the logic based around that, which would negate the need for a parser as far as I can tell.

But if not, maybe the parser would be the better way to go. I said I'd just add a fix for this in the meantime as the parser pr is currently a draft.

@nini-faroux
Copy link
Contributor Author

thanks @jneira - yes the parser would replace all of this and deals with this scenario too I think.

@nini-faroux
Copy link
Contributor Author

I'll close this as #2392 pr will deal with this case also.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants