Opened 3 years ago
Last modified 3 years ago
#13332 new bug
Report unrecognized pragmas earlier
Reported by: | crockeea | Owned by: | |
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | Compiler | Version: | 8.0.2 |
Keywords: | Cc: | ThreeFx | |
Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |
Type of failure: | Poor/confusing error message | Test Case: | |
Blocked By: | Blocking: | ||
Related Tickets: | Differential Rev(s): | ||
Wiki Page: |
Description
In the following example, I have a typo in the UndecidableInstances
pragma (LANGUAGE
is misspelled), however, GHC only reports that UndecidableInstances
is required. This is very confusing, since it appears that I have enabled that pragma.
{-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE FlexibleInstances #-} {-# LANUGAGE UndecidableInstances #-} instance (Num [a]) => Num a
Only when I comment out the instance does GHC report that there is an unrecognized pragma, at which point it became obvious that there was a typo. It would be very helpful if GHC reported the warning about the unrecognized pragma before or at the same time as the error about needing UndecidableInstances
.
Change History (7)
comment:1 Changed 3 years ago by
Keywords: | newcomer added |
---|
comment:2 follow-up: 3 Changed 3 years ago by
comment:3 Changed 3 years ago by
Replying to richardfung:
Hi! I'd like to try my hand at this but was hoping someone could give me some guidance.
From my looking so far, it would appear that the current error message is from somewhere in the typechecker (smallerMsg) while the warning we want to show up is in the Lexer.
I would have expected the warning in the lexer to show up first though since presumably the lexer runs before the typechecker. Could anyone give me a pointer to where I should look to understand what the issue is?
You're correct that the lexer runs before the type checker - after all, you need to know what to typecheck.
I suspect that {-# LANUGAGE UndecidableInstances #-}
is not parsed as pragma but as regular comment. In order to verify this I would look at the lexer and see if this is actually the case. If it isn't, definitely check what this actually gets lexed as - too bad there is no -ddump-lexed
option.
If it is, I'd probably consider adding a lexing warning for unrecognized pragma keywords (LANGUAGE
, OPTIONS_GHC
, ...). Maybe this could also be extended to all pragmas, not only file headers.
Anyway this may be completely wrong - it's just my opinion on where to start. Happy hacking!
comment:4 Changed 3 years ago by
Cc: | ThreeFx added |
---|
comment:5 Changed 3 years ago by
According to the ticket description, GHC does generate a warning about the unknown pragma LANUGAGE
; but only when there isn't an error in the module.
I think there is some logic somewhere for not displaying warnings when there are also errors to report, on the grounds that the errors are more important (and may be the cause of the warnings). However, here clearly the warning about LANUGAGE
is the cause of the consequent errors. We should probably have some notion of "important warnings" that get displayed even when there are errors to report as well.
I think this may have been discussed on another ticket as well, which had a similar sort of issue; but I can't find it at the moment.
comment:6 Changed 3 years ago by
Looking into this a bit more, I think you're right in that the warning is generated. However, I am a little bit confused here because from what I've seen, the error is thrown in checkNoErrs.
checkNoErrs calls failM so the warnings are indeed not shown.
However, even when I print the messages from getErrsVar (via traceTc) there are no warnings. Is that because the warning is not a typecheck warning and thus not stored in the TcRnMonad?
Also, it seems that there's not really a clear path forward on what to do with respect to this ticket. I've enjoyed looking into it as a means to learn more about the internals but I don't think I'm in a position to decide what the best thing to do here is.
comment:7 Changed 3 years ago by
Keywords: | newcomer removed |
---|
I investigated this today.
The relevant code path starts in ghc/Main.hs
under the comment "do the business" which catches and displays errors. Warnings on the other hand are dealt with by runHsc
and are already baked into the HscMonad
. The main logic of how the parser and type checker link together is in hscTypecheck
. The typechecker is invoked by the tcRnModule
function but wrapped with ioMsgMaybe
which throws
an error if the typechecker fails.
It seems like the best solution would be to also stop using throwIO
to report errors and also bake them into the Hsc
type so that runHsc
deals with throwing both warnings and exceptions so we can isolate the logic and which are displayed into one place. I fear that this would be quite a difficult change as a lot of the compiler is designed using these unchecked exceptions.
Thanks for looking at this Richard but I agree that it's not very easy to fix properly.
Hi! I'd like to try my hand at this but was hoping someone could give me some guidance.
From my looking so far, it would appear that the current error message is from somewhere in the typechecker (smallerMsg) while the warning we want to show up is in the Lexer.
I would have expected the warning in the lexer to show up first though since presumably the lexer runs before the typechecker. Could anyone give me a pointer to where I should look to understand what the issue is?