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.

Refactor 'Explore.backjumpInfo' after code review

[ci skip]

Merge branch 'backjumping-space-leak' of https://github.com/grayjay/cabal into grayjay-backjumping-space-leak

Fix space leaks in dependency solver logging.

Previously, a setting of `--max-backjumps=-1` was reported in
the debug output as `0`. But `0` has a very different meaning,
and that is confusing.

(cherry picked from commit 9cd1387fcd582a6131746e6742597069d54f905a)

Improve goal reorder heuristics.

In GHC 8.0 -Wall implies -Wredundant-constraints, so we have to
address those warings in one way or another.

This change primarily does two things:

1. For `--reorder-goals`, we use a dedicated datatype `Degree`
   rather than an `Int` to compute the approximate branching
   degree. We map 0 and 1 to the same value. We then use a
   lazy ordering and a shortcutting minimum function to look
   for the "best" goal.

   The motivation here is that we do not want to spend
   unnecessary work. Following any goal that has 0 or 1 as degree
   cannot really be "wrong", so we should not look at any others
   and waste time.

   This will still not always make the use of `--reorder-goals`
   better than not using it, but it will reduce the overhead
   introduced by it.

2. We use partitioning rather than sorting for most of the other
   goal reordering heuristics that are active in all situations.
   I think this is slightly more straightforward and also slightly
   more efficient, whether `--reorder-goals` is used or not.

I have run some preliminary performance comparisons and they
seem to confirm that in both cases separately (with or without
`--reorder-goals`), these changes are a relative improvement
over the status quo. I will run additional tests before
merging this into master.

[ci skip]

Enable cabal-install integration tests in appveyor.yml

A number of small changes:

- Some comment typos fixed.
- The main function for cycle detection is now called
  `cycleDetectionPhase`, in analogy with all the other
  phases.

I've run a superficial performance test trying to install
all of Hackage on a clean db with ghc-7.10.3. This is not
likely to trigger any situations where cycle detection
actually kicks in, but it confirms in general that there is
no negative performance (or correctness) impact for the
common case.

I've also considered moving the cycle detection phase to
"earlier" in the solver, but after performance testing, decided
against it, and documented the decision and the reasons in
the code.

Fixes #3059.

cabal's handling of non-existent sources depends on the behavior of the
directory package. 'canonicalizePath' can fail on non-existent paths before
directory-1.2.3.0. This commit updates the test 'fail_on_nonexistent_source' to
allow 'cabal sandbox delete-source' to fail or succeed.  It also changes
'fail_removing_source_thats_not_registered' so that it only tests existing
sources.

Merge branch 'pr/DetectCyclesInSolver' of https://github.com/edsko/cabal into edsko-pr/DetectCyclesInSolver

See https://github.com/haskell/cabal/issues/3198#issuecomment-190978842.

Make configPrograms a bit more backward compatible

This implements the suggestion from
https://github.com/haskell/cabal/pull/3196#issuecomment-190285328

Replace Boilerplate Monoid/Semigroup instances with generics

See https://github.com/haskell/cabal/pull/3197#issuecomment-189839042.

This increases compile-time (until GHC becomes more clever) but the
generated code is expected to be at least as good (if not better) than
the manually generated code.

While at it, this removes -XCPP usage from all modules touched.

This addresses #3169

This increases compile-time (until GHC becomes more clever) but the
generated code is expected to be at least as good (if not better) than
the manually generated code.

This addresses #3169

This is preparatory work for implementing #3169
it's kept in a different commit in order to facilitate
comparing code-generation.

This is preparatory work for implementing #3169
it's kept in a different commit in order to facilitate
comparing code-generation.

Turn 'configPrograms' field into a 'Last'-monoid

This implements the suggestions mentioned at
https://github.com/haskell/cabal/issues/3169#issuecomment-189281916

The main benefit of this change is turning 'ConfigFlags' into a uniform
product-type suitable for generic derivation of pointwise
`Semigroup`/`Monoid` instances.

NB: This changes the `Binary` serialisation of `ConfigFlags` since there's
now an additional `Maybe` inserted in `configPrograms`'s type