[ci skip]

[ci skip]

Add a comment to 'Distribution.Solver.Modular.Cycles.findCycles'.

[ci skip]

Edward Z. Yang authored Dec 27, 2016 and Edward Z. Yang committed Jan 02, 2017

A signature package is a package that contains only signatures but no
modules (equivalently, it is a package that has no provisions.)

Previously, we did not treat signature packages any differently from
normal packages, which, in particular, meant that when we instantiated a
package using a signature package, we also instantiated the signature
package.  This is actually pretty useless, because we never actually use
the instantiated signature (there's no code that actually gets compiled
in this case).

This patch treats signature packages specially, so that we don't
actually instantiate dependencies on them.  This means we have
to compile less packages when handling signatures.  Good!

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

Nix integration improvements

Refine the fix for requiring Cabal > 1.20 for Setup.hs

Fixes #4196 

Mention that we allow `shell.nix` or `default.nix`, the same as
`nix-shell`.

cabal only cares if it is running in a Nix shell that was started by
another cabal process, so we should not read IN_NIX_SHELL; rather, we
read a cabal-specific variable for that purpose.

cabal2nix recently changed its generated expressions to read the
IN_NIX_SHELL environment variable. Now we need to set this variable when
calling nix-instantiate to produce the same result as calling nix-shell.

Duncan Coutts authored Oct 29, 2016 and Herbert Valerio Riedel committed Dec 31, 2016

Going along with the existing approach of using a constraint rather than
altering the deps of custom Setup.hs scripts, but make the constraint
only apply to Cabal instances that are dependencies of Setup.hs scripts
not all instances of Cabal.

Also rearrange things a little with a dedicated solver policy function
for adding a min dep on Cabal versions for setup scripts.

Edward Z. Yang authored Dec 30, 2016 and Edward Z. Yang committed Dec 30, 2016

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

Edward Z. Yang authored Dec 27, 2016 and Edward Z. Yang committed Dec 27, 2016

There were a number of fields in 'LinkedComponent' which
were "too" flexible, in that they were fully determined by
other fields in the structure.  This refactor deletes those
fields and replaces them with functions that refer to the
fields directly.

I also introduce a new type, ComponentInclude, to take
the place of tuples which were used to represent includes
(mixins) in Backpack.

There's also more documentation for lots of bits.

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

kristenk authored Dec 18, 2016 and Edward Z. Yang committed Dec 26, 2016

Previously, the solver only checked for cycles after it had already found a
solution. That reduced the number of times that it performed the check in the
common case where there were no cycles. However, when there was a cycle, the
solver could spend a lot of time searching subtrees that already had a cyclic
dependency and therefore could not lead to a solution. This is part of
https://github.com/haskell/cabal/issues/3824.

Changes in this commit:
- Store the reverse dependency map on all choice nodes in the search tree, so
  that 'detectCyclesPhase' can access it at every step.
- Check for cycles incrementally at every step. Any new cycle must contain the
  current package, so we just check whether the current package is reachable
  from its neighbors.
- If there is a cycle, we convert the map to a graph and find a strongly
  connected component, as before.
- Instead of using the whole strongly connected component as the conflict set,
  we select one cycle. Smaller conflict sets are better for backjumping.
- The incremental cycle detection automatically fixes a bug where the solver
  filtered out the message about cyclic dependencies when it summarized the full
  log. The bug occurred when the failure message was not immediately after the
  line where the solver chose one of the packages involved in the conflict. See
  https://github.com/haskell/cabal/issues/4154.

I tried several approaches and compared performance when solving for
packages with different numbers of dependencies. Here are the results. None of
these runs involved any cycles, so they should have only tested the overhead of
cycle checking. I turned off assertions when building cabal.

Index state: index-state(hackage.haskell.org) = 2016-12-03T17:22:05Z
GHC 8.0.1

Runtime in seconds:
Packages                    Search tree depth   Trials   master   This PR   #1      #2
yesod                       343                 3        2.00     2.00      2.13    2.02
yesod gi-glib leksah        744                 3        3.21     3.31      4.10    3.48
phooey                      66                  3        3.48     3.54      3.56    3.57
Stackage nightly snapshot   6791                1        186      193       357     191

Total memory usage in MB, with '+RTS -s':
Packages                                        Trials   master    This PR   #1     #2
yesod                                           1         189       188       188     198
yesod gi-glib leksah                            1         257       257       263     306
Stackage nightly snapshot                       1        1288      1338      1432   12699

#1 - Same as master, but with cycle checking (Data.Graph.stronglyConnComp) after
     every step.
#2 - Store dependencies in Distribution.Compat.Graph in the search tree, and
     check for cycles containing the current package at every step.

Fix #3440.

Fix provided by @mvkorpel.

[ci skip]

Mark `template-haskell` non-upgradable (again)

Depend on echo to fix #4128

65e9b88b made template-haskell non-upgradable

65ae95c1 made it upgradable again

...and this commit makes it non-upgradable again

While there may be a few cases when `template-haskell` can be
reinstalled, it's generally not advisable, and causes more harm than the
benefit in the few cases where we'd gain install-plan
flexibility (e.g. when only template-haskell's API is needed for
compile, but no actual TH evaluation takes place).

Closes #4098

This reverts commit eca045bc.

Revert "Add fingerprint of Generic representation when serializing."

This reverts commit ebcae71d.

cabal-version semantics prior to 1.8 joined all `build-depends`;
as suggested by @ezyang it's easier for now to just fallback to
legacy mode, than to add proper support for per-components builds
for ancient cabal-spec versions

Fixes #4121

adding ghc-prof-options to fprof warning

Edward Z. Yang authored Dec 17, 2016 and Edward Z. Yang committed Dec 17, 2016

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

Edward Z. Yang authored Oct 18, 2016 and Edward Z. Yang committed Dec 17, 2016

GHC will make use of this to do more accurate shadowing computation,
because now we can tell if something is ABI-compatible, even if the 'id'
matches.

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

Edward Z. Yang authored Oct 18, 2016 and Edward Z. Yang committed Dec 17, 2016

This is similar to what we do in Distribution.Simple.Build;
preparatory commit so we can read out the ABI hashes of
our dependencies from installedPkgs.

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

fixes #3718

Bump directory upper bound

Edward Z. Yang authored Dec 12, 2016 and Edward Z. Yang committed Dec 13, 2016

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

Edward Z. Yang authored Dec 12, 2016 and Edward Z. Yang committed Dec 13, 2016

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