Skip to content

Introduce a selection of error domain-specific types

Alfredo Di Napoli requested to merge adinapoli/ghc:adinapoli/introduce-error-domain-specific-types into master

This MR sets the foundation for the new GHC's error hierarchy (#18516). For each phase of the compilation pipeline, we define:

  • A GHC.XXX.Errors module which contains useful functions to deal with errors for that particular phase (cfr. GHC.Driver.Errors to see what I mean by "useful functions");
  • A GHC.XXX.Errors.Types module where the error types are defined;
  • A GHC.XXX.Errors.Types.Ppr module where the pretty-printing / rendering is defined. This reduces the chances of circular imports and the need for boot modules;

On top of this, the GHC.Driver.Errors.Types also contains a top-level umbrella type called GhcMessage, which is meant to be used almost at the boundary with application code (e.g. GHC.Driver.Main), or in situations where we really need a monomorphic Messages e type (cfr. GHC.Types.SourceError).

This MR just adds a selection of the possible messages, and it doesn't actually use them. The idea is to perform the porting gradually, to minimise churning and for ease of code-reviewing. No messages are provided for the HsToCore phase, mostly because currently GHC uses the same errors for both TcRn and HsToCore, so extra work is needed to disentangle the two.

This MR depends on !4728 (closed) and !4747 (closed).

@rae I suggest reviewing this possibly after !4728 (closed) has been merged, as the changes provided by the former might hinder the code review a bit (just because they clutters the real changes of this MR).

Edited by Alfredo Di Napoli

Merge request reports