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

sheaf (@sheaf) gitlab at gitlab.haskell.org
Mon May 22 10:44:59 UTC 2023



sheaf pushed to branch wip/t22884 at Glasgow Haskell Compiler / GHC


Commits:
0d86c126 by Matthew Pickering at 2023-05-22T12:44:51+02: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).

- - - - -
80c82029 by Matthew Pickering at 2023-05-22T12:44:51+02: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.

- - - - -
c87ea852 by Matthew Pickering at 2023-05-22T12:44:51+02: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.

- - - - -
3bbd45bb by Matthew Pickering at 2023-05-22T12:44:51+02: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/CmdLine.hs
- compiler/GHC/Driver/Config/Diagnostic.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/60c301500086068ae9f3230ff6174595d1f16a0c...3bbd45bb4d85bd996f6662058ee204a63fe0bf38

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/60c301500086068ae9f3230ff6174595d1f16a0c...3bbd45bb4d85bd996f6662058ee204a63fe0bf38
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/20230522/f9f10ef9/attachment-0001.html>


More information about the ghc-commits mailing list