GitLab

and check internal invariants

Implement it in terms of the -XRecordPuns which was accidentally
added in ghc-6.8 and deprecates in 6.10 in favor of NamedFieldPuns
So this is for compatability so we can tell package authors always
to use NamedFieldPuns instead.

Along with possibly another extension that replaces it.

Check for new language extensions added in Cabal-1.2 and also 1.6.
Simplify the checking of -X ghc flags. Now always suggest using
the extensions field, as we separately warn about new extenssons.

Provide asVersionIntervals as the view function for a VersionRange
This will let us enforce the internal data invariant

Previously if one or the other or both were missing we only warned.
Now if neither are given it's an error. We still warn about either
missing.

For Functor, Monoid and Traversable.

Since Cabal-1.4 we've been able to parse versioned licenses
and unknown licenses without the parser falling over.

It's pretty meaningless since it's only a syntactic check.
The proper thing is to maintain a dependency set or to
simplify dependencies before printing them.

Instead of matching on the actual expression ">= x.y" we use the
sematic view of the version range so we can do it precisely.
Also use foldVersionRange to simplify a couple functions.

It's still possible to build with ghc-6.4 but you have to pass
extra flags like "ghc --make -cpp -fffi Setup.hs" We could not
keep those OPTIONS pragmas and make it warning-free with ghc-6.10.
See http://hackage.haskell.org/trac/ghc/ticket/2800 for details.

Export constructor functions and deprecate all the real constructors
We should not be pattern matching on this type because it's just
syntax. For meaningful questions we should be matching on the
VersionIntervals type which represents the semantics.

Also add simplify and isNoVersion.

as a sequence of non-overlapping intervals. This provides a canonical
representation for the semantics of a VersionRange. This makes several
operations easier.

Use it to simplify the eval / withinRange function

It requires cabal-version: >= 1.6 to be specified

It requires Cabal-1.6 or later.

Rather than encoding them in existing constructors.
This will enable us to check that uses of the new syntax
are flagged in .cabal files with cabal-version: >= 1.6

Yes, LHC really does use ghc-pkg (with a different package.conf)