Previously, the solver filtered out redundant backjumping messages twice, once
in 'Log.logToProgress' and again in 'Message.showMessages. However,
'showMessages' relied on the backjumping messages to determine where to insert
messages about missing packages. This led to missing "unknown package" messages
(part of issue #3617).

This commit removes the filtering in 'logToProgress', because it was redundant.

Revert "Generalize HookedBuildInfo to work with any type of component."

fix exception handling of downloads in new-build

Don't test sdist in the main script.

See https://github.com/haskell/cabal/pull/3630#issuecomment-235438329.

[ci skip]

Test travis

This reverts commit af7bb537,
restoring 'HookedBuildInfo' backwards compatibility.

Download errors are now put into the residual install plan, like other
build errors.

Fixes issue #3387

Split things up a little so the generic async fetch can live with the
other fetch utils. This also makes it easier to test.

Change the exception handling so that any exception in fetching is
propagated when collecting the fetch result.

As a result of the previous InstallPlan refactoring, we can now use the
non-serialisable BuildFailure type from D.C.Types which uses
SomeException, where previously we had to use a copy of that type that
used String for the errors.

So now there's no longer any need to have a separate set of types for
BuildResult, BuildResults, BuildSuccess or BuildFailure. There was a
minor difference in the structure of the BuildSuccess, where in the new
build code we need to be able to produce the InstalledPackageInfo at a
different point from the rest of the info in the BuildSuccess. This can
be kept local to the ProjecBuilding module, but accounts for the
somewhat larger number of changes in that module.

PackageTests/Configure: Use zlib instead of X11.

Fixes (part of) #3623.

[ci skip]

Compat prelude

Make internal/self-exect setup methods more chatty.

Compile an actual executable, don't use `ghc -e` to provide gibberish
printing binary.

Installplan refactor

Add an IsNode instance for Either.

LocalBuildInfo: combine profiling settings, track program coverage

Edward Z. Yang authored Jul 24, 2016 and Duncan Coutts committed Jul 25, 2016

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

These were used previously for the Installed and Failed package states,
but these states are now gone.

Importantly this now means that we can have a serialisable InstallPlan
without the failure types having to be serialisable. This means we can
use things like SomeException which is not serialisable. Since the
traversal is done separately, the result of the traversal contains the
failure values, but this result set does not have to be serialised.

We now just have the initial states, PreExisting and Configured. The
Processing, Installed and Failed states are gone. We now do traversals
separately from the InstallPlan, so we no longer need these states.

Rename from prime' versions to the normal names, now that the old ones
have been removed.

There were two uses other than excuteInstallPlan. The new ready impl can
be used in both these cases, allowing the old one to be removed.

These were the primitives used by executeInstallPlan to change the
package states to Processing, Installed, Failed etc.

The 'ready' is still used in a couple other places, so those need to be
modified before the old 'ready' can be removed.

Redefine the local executeInstallPlan util in terms of
InstallPlan.execute. Of course now executeInstallPlan returns
BuildResults instead of an upated InstallPlan. This requires changes in
all the code that looks at the result of the build execution, including
console error reporting, build reports, symlinks etc.

Eliminate the local executeInstallPlan. The main change is that the new
execute returns BuildResults instead of an upated InstallPlan. This has
a few knock-on conseuqnces for the code that looks at the result of the
build execution.

Currently we don't actually do that much with the results in the
new-build code path (though we should) so there's less disruption than
one might imagine. The biggest change is in the integration tests which
do inspect the execution result to check things worked or didn't work as
expected.

The equivalent change for the old build code path will be more
disruptive since it does a lot of stuff with the execution results.

This is intended to replace a couple existing executeInstallPlan
implementations.

The tests check that execute visits packages in reverse topological
order, for both serial and parallel job control. There's also a check
that serial execute and executionOrder use exactly the same order.