Report unrecognized pragmas earlier

[crockeea]

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.

[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?

[ThreeFx]

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!

[rwbarton]

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.

[richardfung]

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.

[mpickering]

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.