Closed gromakovsky closed 4 years ago
It's better to enable -Werror
on CI only instead of always, otherwise development and building on newer GHC versions with allow-newer: True
becomes difficult.
I can add a Makefile
which would pass --ghc-options -Wwarn
. In this case if we switch to another CI we won't accidentally forget to enable -Werror
.
Imagine there's a package x
which depends on universum
. How would it disable -Werror
? Passing -Wwarn
would only affect x
itself, and having a Makefile for universum
would not be helpful at all.
Does --ghc-options -Werror
in universum.cabal
matter when one builds x
? I thought no, but if it matters then yes, probably it's better to do it differently.
Does
--ghc-options -Werror
inuniversum.cabal
matter when one buildsx
?
Yes. ghc-options
from the .cabal
file are in effect if the package is being built as a dependency of another package (why would they be ignored?)
Ok, now it's different.
Description
Here I enable all warnings that I find sane, enable
-Werror
and fix new warnings.Related issues(s)
Fixed #185.
✓ Checklist for your Pull Request
Ideally a PR has all of the checkmarks set.
If something in this list is irrelevant to your PR, you should still set this checkmark indicating that you are sure it is dealt with (be that by irrelevance).
Related changes (conditional)
Tests
Documentation
I checked whether I should update the docs and did so if necessary:
Record your changes
Stylistic guide (mandatory)
[x] My commit history is clean (only contains changes relating to my issue/pull request and no reverted-my-earlier-commit changes) and commit messages start with identifiers of related issues in square brackets.
Example:
[#42] Short commit description
If necessary both of these can be achieved even after the commits have been made/pushed using rebase and squash.