Skip to content

MessageClass and Severity types for diagnostic messages

Alfredo Di Napoli requested to merge adinapoli/ghc:adinapoli/message-class into master

This MR stemmed from @rae's branch simplify-errors, and historical context is given below. We still want to eventually merge Richard's branch but we are proceeding one bite at the time.

The current Severity type in GHC is not very satisfactory, because it conflates two concerns: the need for logging different kind of messages via the putLogMsg function and the need for categorising errors and warnings.

data Severity
  = SevOutput
  | SevFatal
  | SevInteractive
  | SevDump
    -- ^ Log message intended for compiler developers
    -- No file\/line\/column stuff
  | SevInfo
    -- ^ Log messages intended for end users.
    -- No file\/line\/column stuff.
  | SevWarning
  | SevError
    -- ^ SevWarning and SevError are used for warnings and errors
    --   o The message has a file\/line\/column heading,
    --     plus "warning:" or "error:",
    --     added by mkLocMessags
    --   o Output is intended for end users
  deriving (Eq, Show)

This is not satisfactory, because it might lead to the construction of "impossible states" where by accident we could create a new MsgEnvelope which has errMsgSeverity SevDump, which would be nonsense, considering we rely on the Severity to distinguish between warnings and errors.

This patch fixes that. This MR mostly builds on top of the original Richard's commit, but without going too far. Richard's branch has also refactorings to fix the errors and warnings categorisation, but we couldn't fix all the test right away so this is the smallest change that should deliver value without breaking anything.

There is a novel aspect that this patch introduces over Richard's one, i.e. that now we define:

data Severity
  = SevWarning !WarnReason -- ^ Born as a warning or demoted from an error.
  | SevError   !ErrReason  -- ^ Born as an error  or promoted from a warning (e.g. -Werror)
  deriving (Eq, Show)

That is, exactly like we used to have a (very overloaded) WarnReason, we now have a dual ErrReason, which further reinforces this idea of a fluid relationship between warnings and errors. The ErrReason allows to encapsulate more clearly the "provenance" (i.e. was this born as an error or is this a promoted warning due to -Werror or -Werror=flag ?). Without a more sophisticated ErrReason type, sometimes we were losing the nuance of the promotion/demotion, which made easier to introduce bugs during refactoring.

The rest of the "Severities" have been moved into a separate type called MessageClass, which is used during logging of generic messages, not compiler diagnostics.

Merge request reports