`cabal check`: Warn about "bad" bounds

[andreasabel]

A few insights into bounds that cabal check could teach the users via some new warnings:

1. A lower bound should be inclusive, i.e. of the form >= version, and not exclusive, i.e. > version. Common blunders could be base > 4.11 when you actually want base >= 4.12. Note that versions make a dense space, so there are infinitely many versions that are > 4.11 and < 4.12.
2. An upper bound should be exclusive, i.e., of the form < version, and not inclusive, i.e. <= version. A blunder I observed in the wild is folks setting e.g. base <= 4.19.1.0 when the last published version of base is 4.19.1.0. This way, one blocks patch releases that should always be fine according to the PVP. The correct minor bound is base < 4.19.2.
3. An upper bound should not have trailing zeros. E.g. base < 4.20.0.0 could be mistaken to mean that base-4.19.* is the latest versions that should be accepted. But really base-4.20 and base-4.20.0 are not excluded by the bound. The correct bound is < 4.20.

I propose that cabal check warn on subexpressions of the version range that are of the form > version or <= version. It should further warn on upper bounds with trailing zeros, i.e. <= version.0...0.

[andreasabel]

Here is another case of bad upper bounds in the wild: https://hackage.haskell.org/package/concurrent-output-1.10.21/concurrent-output.cabal

build-depends: ...
    , process (>= 1.6.0 && < 1.7.0)
    , directory (>= 1.2.0 && < 1.4.0)
    , transformers (>= 0.3.0 && < 0.7.0)
    , exceptions (>= 0.6.0 && < 0.11.0)
    , ansi-terminal (>= 0.6.2 && < 1.2.0)

[ulysses4ever]

@ffaf1 does this look plausible?

[ffaf1]

It does!