Moritz Angermann
Does this need to be *this* hardcoded? Or could we just parse the pragma and compare it to a list of known pragmas to be parsed from a file (or settings value?).
To be clear, I don't think we want to start considering `settings` to be a user configuration file. In my mind `settings` is something that is produced and consumed by GHC itself and I don't believe we want to change that.
The change in question does:
- pragmas = options_pragmas ++ ["cfiles", "contract"] + pragmas = options_pragmas ++ ["cfiles", "contract", "hlint"]
to the `compiler/parser/Lexer.x`, and as such is somewhat hardcoded. So we already ignore a bunch of `option_` and those three pragmas.
And I see
<0,option_prags> { "{-#" { warnThen Opt_WarnUnrecognisedPragmas (text "Unrecognised pragma") (nested_comment lexToken) } }
which I believe handles the unrecognisedPragmas case.
Can't we have a ignored-pragmas value in the settings, that just lists all those we want to ignore, instead of hardcoding them in the Lexer?
That at least feels to me like a less invasive (and easier to adapt) appraoch, that might be less controversial? Yes it's just moving goal posts, but it moves the logic into a runtime value instead of a compile time value.
I don't think it fundamentally changes the problem: another tool would still be unable to use the same syntax that HLint uses without getting a patch into GHC. This seems wrong to me. Cheers, - Ben