kristenk authored Apr 11, 2016 and Edsko de Vries committed Apr 21, 2016

This commit replaces a call to 'lgBlame' with a call to 'lgConflictSet'.
'lgConflictSet' adds the members of the link group to the conflict set. The
other members are required, for example, when a linked package's version doesn't
match a constraint, and the solver must try other versions for the linked-to
package.

All tests now pass.

When we are choosing to link a package (`pickLink`), it is possible that that
package was _already_ linked (because its reverse dependencies got linked).
Thus, this requires a merge of link groups: it is not correct to simply add the
package into the target link group.

This fixes #2842.

This commit is a pure refactoring, no semantic changes. Submitting as separate
PR at @kosmikus request.

Tihs moves `ConflictSet` and `Var` into their own modules.

When solving, we now discard plans that would involve packages with a
pkgconfig-depends constraint which is not satisfiable with the current
set of installed packages (as listed by pkg-config --list-all).

This fixes https://github.com/haskell/cabal/issues/3016.

It is possible (in principle, although it should be basically impossible
in practice) that "pkg-config --modversion pkg1 pkg2... pkgN" fails to
execute for various reasons, in particular because N is too large, so
the command line becomes too long for the operating system limits.

If this happens, revert to the previous behavior of accepting any
install plan, regardless of any pkgconfig-depends constraints.

Every package now "depends" on all language extensions
(default-extensions and other-extensions) and language flavours
(default-language and other-languages) it declares in its cabal file.

During solving, we verify that the compiler we use actually
supports selected extensions and languages. This has to be done
during solving, because flag choices can influence the declared
extensions and languages being used.

There currently is no equivalent check performed on the generated
install plans. In general, cabal-install performs a sanity check
on the solver output, checking that the solver e.g. indeed includes
all the declared dependencies of a package. There is no such
double-checking for language extensions. This is not really
problematic, as all that this change does is to make the solver
more conservative rather than less. However, having a sanity check
available might ultimately be nice to have.

We previously recorded the canonical package and the instance of a link group
separately, but it turns out we can always record these together: when we know
one we know the other. This makes various choices a lot clearer.

Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10798823
Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10798983
Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10799096
Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10799127
Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10799454
Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10799467
Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10799561
Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10799579
Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10799827
Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10799865
Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10799896

https://github.com/haskell/cabal/pull/2500#commitcomment-10799127

Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10798823

Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10798623

Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10455653
Addresses https://github.com/haskell/cabal/pull/2500#commitcomment-10797900

This happened independently in a number of places, which was bad; and was about
to get worse with the base 3/4 thing.

The modular solver has its own representation for a package (PInfo). In this
commit we modify PInfo to keep track of the different kinds of dependencies.

This is a bit intricate because the solver also regards top-level goals as
dependencies, but of course those dependencies are not part of any 'component'
as such, unlike "real" dependencies. We model this by adding a type parameter
to FlaggedDeps and go which indicates whether or not we have component
information; crucially, underneath flag choices we _always_ have component
information available.

Consequently, the modular solver itself will not make use of the ComponentDeps
datatype (but only using the Component type, classifying components); we will
use ComponentDeps when we translate out of the results from the modular solver
into cabal-install's main datatypes.

We don't yet _return_ fine-grained dependencies from the solver; this will be
the subject of the next commit.

This is implemented as a separate pass so that it can be understood
independently of the rest of the solver.