After a parse error in OPTIONS_GHC issue an error message instead of a compiler panic.
Details
make test TEST=T15053
Diff Detail
- Repository
- rGHC Glasgow Haskell Compiler
- Branch
- T15053
- Lint
Lint OK - Unit
No Unit Test Coverage - Build Status
Thanks for the patch @RolandSenn , the code itself is fine, just not sure about the error message. I also can't remember if we emit error messages in GHC in past or present tense.. so CC @osa1
compiler/main/HeaderInfo.hs | ||
---|---|---|
346 | Should probably be white-space separated. @osa1 Did you have any opinions on the error message? |
Agreed: white-space separated is much better! My version of the error message is just a first proposal.
ok, how about something like Error while parsing OPTIONS_GHC pragma, expected whitespace delimited list of options. Input was " -O1 }\n\"\n "
testsuite/tests/parser/should_fail/T15053.stderr | ||
---|---|---|
5 | "non-parsable" or "nonparsable", I think. "non" is not an adjective / adverb. |
Thanks @RolandSenn! Added a minor comment about the error message.
compiler/main/HeaderInfo.hs | ||
---|---|---|
346 | Sorry saw this too late. I think this is fine but to be more consistent with existing error messages can we do something similar to languagePragParseError? E.g. Cannot parse OPTIONS_GHC pragma Expecting whitespace-separated list of GHC options E.g. {-# OPTIONS_GHC -Wall -O2 #-} Input was: ... |
Ah so you wanted to update languagePragParseError too? Why? To be clear, your wording is fine (but note that I'm also not a native speaker ;-), my concern is about consistency and not the choice of words of tense.
Ah so you wanted to update languagePragParseError too? Why?
No, no, no! I didn't want to change the language pragma message text! To write the options pragma message, I copied the message text from languagePragParseError to optionsParseError and modified the copied text until I had what was in my first commit.
I now changed to the error message, that's more consistent with the error message issued on a LANGUAGE pragma error.