ghc-clippy-plugin alternatives and similar packages
Based on the "ghc" category.
Alternatively, view ghc-clippy-plugin alternatives based on common mentions on social networks and blogs.
Type checker plugins without the type checking.
Do you think we are missing an alternative of ghc-clippy-plugin or a related project?
GHC Clippy Plugin
A helpful companion to GHC.
Overrides GHC error and warning messages, to the user's liking.
Configured using (how else!) regexps. Tested with stack and ghcid.
Left: without Clippy.
Right: with Clippy, using the sample config.
For all kinds of reasons:
- making GHC messages more terse or more verbose
- adding more context for beginners
- stripping confusing / duplicated / rarely useful context for everyone
- prototyping improvements for ghc error output
- ever wanted GHC to speak in emoji? :smiling_imp:
- ... or in your mother tongue?
- ... or in mathematical notation?
- Add the
ghc-clippy-plugindependency to your project
-fplugin=Clippyin GHC options
E.g. for stack:
# file: package.yaml dependencies: - ghc-clippy-plugin ghc-options: - -fplugin=Clippy
- When building, you should see the following warning:
ghc-clippy-plugin: warning: Clippy plugin couldn't start. Cause: ./.clippy.dhall: openFile: does not exist (No such file or directory)
Make sure there was anything to compile (change a .hs file) if the warning wasn't there.
Save the [sample config](/.clippy-terse.dhall) as
.clippy.dhall in the project's root dir
(or - more precisely - the
current directory GHC is going to use)
- Put an error somewhere:
oops = print mempty
With the sample config, this should output:
./app/Main.hs:19:14-19: error: Type variable ‘a0’ is ambiguous in ‘mempty’. Can't pick an instance for ‘(Monoid a0)’. --- Maybe-fix: add type annotations to disambiguate. More info: compile with -fprint-potential-instances. | 19 | oops = print mempty |
- Enjoy the much terser output and tweak it to your heart's content! :grin:
Tweaking the config
--file-watch to pick up config changes, add in
extra-source-files: - .clippy.dhall
stack build --file-watch. Make sure to have some errors handy! :)
For ghcid to reload after config change, run it with
I tend to put the above line in
Ghcid may terminate if there are compile errors on startup. If that's the case, remove your errors until ghcid starts successfully :)
With the above, for error messages, ghcid picks up
.clippy.dhall changes immediately.
For warnings, one needs to trigger recompilation of the file triggering them.
One way around that is to enable
-Werror for the period of config tweaking.
(I put mine in
Error message structure, section markers
In GHC, each error/warning message contains 3 sections in its ErrDoc
('Important', 'Context', and 'Supplementary'). Each section contains a list of
Before replacing the message text, Clippy wraps each section, and each of their
markers. This allows for more precise match targeting, including MsgDoc/section ends.
To see the structure of the replaced error message, comment out the
marker removing rule in the
rules = [ -- rule "(>>[ICS]>)|(<[ICS]<<)|(>[ICS]>)|(<[ICS]<)" "" , rule "..." "..." -- ... ]
Comment out all rules to see the structure of the original message. Sample result:
./app/Main.hs:27:11: error: • >>I> >I> No instance for (Num a) arising from a use of ‘+’ Possible fix: add (Num a) to the context of the type signature for: bar :: forall a. a -> a -> a <I< <I<< • >>C> >C> In the expression: a + b In an equation for ‘bar’: bar a b = a + b <C< <C<< • >>S> <S<< | 27 | bar a b = a + b |
Replace rules can span across multiple messages in a section, but can't cross section boundaries. For example, the following rule will remove the entire 'Context' section:
rule "(?s)>>C>.*?<C<<" "" -- notice the (?s) - "dot-all" regex flag
All-whitespace lines are removed from all the messages.
Rule matching order
Replacement rules are applied in reverse order of the
rules list in config.
This means the most generic and least selective rules should go at the top of the file.
In particular, the
marker removing rule - which should be applied last - should be
the first rule in every config.
I'd like to thank the authors of
- the Scala Clippy Plugin for the name and the idea
- Error Messages in Haskell, and how to Improve them for inspiration and some initial test cases
- Understanding Basic Haskell Error Messages for test cases as well
- the wonderful folk working on GHC, for making this possible :heart:
- resolve the config from the first directory above that contains
- fall back to
~/.config/clippy.dhalland then to
- cache the config instead of re-parsing for every module
*Note that all licence references and agreements mentioned in the ghc-clippy-plugin README section above are relevant to that project's source code only.