[Git][ghc/ghc][wip/t22884] 4 commits: Generalise UnknownDiagnostic to allow embedded diagnostics to access

Matthew Pickering (@mpickering) gitlab at gitlab.haskell.org
Wed May 10 14:53:07 UTC 2023



Matthew Pickering pushed to branch wip/t22884 at Glasgow Haskell Compiler / GHC


Commits:
a68adbe3 by Matthew Pickering at 2023-05-10T15:47:31+01:00
Generalise UnknownDiagnostic to allow embedded diagnostics to access
parent diagnostic options.

* Split default diagnostic options from Diagnostic class into
  HasDefaultDiagnosticOpts class.
* Generalise UnknownDiagnostic to allow embedded diagnostics to access
  options.

The principle idea here is that when wrapping an error message (such as
GHCMessage to make GHCiMessage) then we need to also be able to lift the
configuration when overriding how messages are printed (see load' for an
example).

- - - - -
556bc70b by Matthew Pickering at 2023-05-10T15:47:31+01:00
Allow API users to wrap error messages created during 'load'

This allows API users to configure how messages are rendered when they
are emitted from the load function. For an example see how
'loadWithCache' is used in GHCi.

- - - - -
44b4467d by Matthew Pickering at 2023-05-10T15:47:31+01:00
Abstract cantFindError and turn Opt_BuildingCabal into a print-time option

* cantFindError is abstracted so that the parts which mention specific
  things about ghc/ghci are parameters. The intention being that
  GHC/GHCi can specify the right values to put here but otherwise
  display the same error message.
* The BuildingCabalPackage argument from GenericMissing is removed and
  turned into a print-time option. The reason for the error is not
  dependent on whether `-fbuilding-cabal-package` is passed, so we don't
  want to store that in the error message.

- - - - -
3635f32f by Matthew Pickering at 2023-05-10T15:47:31+01:00
error messages: Don't display ghci specific hints for missing packages

Tickets like #22884 suggest that it is confusing that GHC used on the
command line can suggest options which only work in GHCi.

This ticket uses the error message infrastructure to override certain
error messages which displayed GHCi specific information so that this
information is only showed when using GHCi.

The main annoyance is that we mostly want to display errors in the same
way as before, but with some additional information. This means that the
error rendering code has to be exported from the Iface/Errors/Ppr.hs
module.

I am unsure about whether the approach taken here is the best or most
maintainable solution.

Fixes #22884

- - - - -


30 changed files:

- compiler/GHC/Driver/Backpack.hs
- compiler/GHC/Driver/Config/Diagnostic.hs
- compiler/GHC/Driver/Errors.hs
- compiler/GHC/Driver/Errors/Ppr.hs
- compiler/GHC/Driver/Errors/Types.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/HsToCore/Errors/Ppr.hs
- compiler/GHC/HsToCore/Errors/Types.hs
- compiler/GHC/Iface/Errors.hs
- compiler/GHC/Iface/Errors/Ppr.hs
- compiler/GHC/Iface/Errors/Types.hs
- compiler/GHC/Parser/Errors/Ppr.hs
- compiler/GHC/Parser/Errors/Types.hs
- compiler/GHC/Tc/Errors/Ppr.hs
- compiler/GHC/Tc/Errors/Types.hs
- compiler/GHC/Types/Error.hs
- compiler/GHC/Types/Error/Codes.hs
- docs/users_guide/9.8.1-notes.rst
- ghc/GHCi/UI.hs
- ghc/GHCi/UI/Exception.hs
- testsuite/tests/driver/multipleHomeUnits/multipleHomeUnitsModuleVisibility.stderr
- testsuite/tests/ghc-api/target-contents/TargetContents.stderr
- testsuite/tests/ghc-e/should_run/T2636.stderr
- testsuite/tests/module/mod1.stderr
- testsuite/tests/module/mod2.stderr
- + testsuite/tests/package/T22884.hs
- + testsuite/tests/package/T22884.stderr
- + testsuite/tests/package/T22884_interactive.script


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/87299e2831abfc6f90475e3d380ea03fd6a3e37f...3635f32fe170a3b4a85d10ba56d576f9bea16df0

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/87299e2831abfc6f90475e3d380ea03fd6a3e37f...3635f32fe170a3b4a85d10ba56d576f9bea16df0
You're receiving this email because of your account on gitlab.haskell.org.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20230510/8b91b5e6/attachment.html>


More information about the ghc-commits mailing list