Commits · 021689e10bbf1234bbfd48837fe768f5debf13c3 · Glasgow Haskell Compiler / Packages / Cabal

This project is mirrored from https://github.com/haskell/Cabal. Pull mirroring updated 30 minutes ago.

Oct 01, 2019
- Skip few tests on windows · 021689e1
  Oleg Grenrus authored 5 years ago
  
  021689e1
Mar 13, 2019

Skip bkpcabal01 test on GHC 8.2.2 due to #4908 · 011de3d2
Herbert Valerio Riedel authored 6 years ago
```
Also tweaks testcase's .cabal metadata
```
011de3d2

Fix #5929 by replicating logic from Cabal in cabal-install. · 0afc8fba

Edward Z. Yang authored 6 years ago


Alas, we can't deduplicate the code because the fine structure is
a bit different, but it's basically the same fix as in the Cabal case.

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

0afc8fba

Mar 09, 2019
- Add bpkcabal01 regression test-case · 9fe8d381
  Herbert Valerio Riedel authored 6 years ago
  
  9fe8d381
Jan 30, 2019
- Add missing expect file. · c2163dee
  Edward Z. Yang authored 6 years ago
  
  Signed-off-by: Edward Z. Yang <ezyang@fb.com>
  c2163dee
Jan 28, 2019
- Make it actually work · 05786f7a
  Edward Z. Yang authored 6 years ago
  
  Signed-off-by: Edward Z. Yang <ezyang@fb.com>
  05786f7a
Dec 17, 2018
- More test fixes. · 9da78740
  Alexis Williams authored 6 years ago
  
  9da78740
- Canonicalize `v2-` as standard prefix, update a bunch of tests · 3dbcb15a
  Alexis Williams authored 6 years ago
  
  3dbcb15a
Nov 03, 2018
- Revert "TEMPORARILY accept test with duplicate output" · ed1c6b0d
  Francesco Gazzetta authored 6 years ago
  
  This reverts commit 1c4ad06c4490125ee43ae4d8fe66a8dde95aa8c7. The previous commit fixed it
  ed1c6b0d
- TEMPORARILY accept test with duplicate output · e623b190
  Francesco Gazzetta authored 6 years ago
  
  e623b190
Jun 22, 2018
- Update tests to accomodate output changes in GHC HEAD. · f48bdb46
  quasicomputational authored 6 years ago
  
  f48bdb46
Jan 31, 2018

Allow erroneous warning for now. · 73713efb

John Ericson authored 8 years ago

Eventually, configuring will be rewritten so extra constraints do note pollute
the checks. When that happens this commit should be reverted.

73713efb

Jan 16, 2018

Implement preliminary support for new forward-compat scheme · 538f1269

Herbert Valerio Riedel authored 7 years ago and

Oleg Grenrus committed 7 years ago

This provides a provisional (i.e. hacky) retrofitted implementation of
the forward-compat scheme described in #4899 for the cabal-2.2 branch

This hack works by constructing a dummy package description in case
the package description fails to be parsed via the standard parser,
and we detect a new-style cabal-spec declaration.

538f1269

Jan 10, 2018

Rerun dependency solver to generate a better error message (issue #4823). · 5d3618a1

kristenk authored 7 years ago

This commit changes the way that the solver generates the summarized log that it
displays at normal verbosity.

Previously, the solver saved the full log from the start to the first backjump.
Then it filtered the log using the conflict set from the node where the first
backjump occurred, i.e., it removed all lines from the log that did not relate
to variables in the conflict set.  The solver also printed the final conflict
set at the end of the log.

This approach had several problems:

1. It was possible for the conflicts at the first backjump to be unrelated to
   the final conflict set (issue #941).  The conflicts in the summarized log
   could be irrelevant to the failure, for example, if they were caused by only
   a single version of a dependency, which the solver could skip, and the real
   problem was a different dependency that was missing from the index.  Even if
   the summarized log was relevant, showing two different explanations for the
   same failure could be confusing.

2. Filtering the full log was error prone and could remove the wrong lines.  It
   caused bugs mentioned in #2853 and #4154.

3. The conflict set at the first backjump contains the variables directly
   involved in the conflicts at that level and the variables that introduced
   them, but it doesn't contain the whole chain of variables starting with the
   user targets (issue #4792).  When the log is filtered with that conflict set,
   it can be unclear why the solver needed to choose the conflicting packages in
   the first place.

This commit creates the summarized log by rerunning the solver with a backjump
limit of zero and using the full log.  Using an unfiltered log avoids (2) and
(3).  However, it is also important to shorten the log by only showing choices
that are relevant to conflicts.  This commit uses different approaches for the
two types of solver failures.

No solution:

This commit makes the solver prefer variables from the first run's final
conflict set when choosing goals in the second run.  This means that the log to
the first backjump is more likely to be relevant to the final failure, because
it only mentions packages, flags, and stanzas from the final conflict set.

Backjump limit reached:

There is no final conflict set in this case, since the solver did not traverse
the whole tree.  This commit tries to create a final conflict set by rerunning
the solver with a subtree of the original search tree that contains the path to
the first backjump.  Then it uses the final conflict set from that run to
generate a log message, as in the case where the solver found that there was no
solution.

Here is an example of the differences between the new and old logs, using the
command from issue #4792 and GHC 8.2.1:

Before:

$ cabal install --dry-run --index-state=2018-01-04T21:05:55Z thorn
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: base-4.10.0.0/installed-4.1... (dependency of thorn)
next goal: profunctors (dependency of thorn)
rejecting: profunctors-5.2.1, profunctors-5.2, profunctors-5.1.2,
profunctors-5.1.1, profunctors-5.1, profunctors-5.0.1, profunctors-5.0.0.1,
profunctors-5 (conflict: thorn => profunctors<5)
trying: profunctors-4.4.1
next goal: transformers (dependency of profunctors)
rejecting: transformers-0.5.2.0/installed-0.5..., transformers-0.5.5.0,
transformers-0.5.4.0, transformers-0.5.2.0, transformers-0.5.1.0,
transformers-0.5.0.1, transformers-0.5.0.0 (conflict: profunctors =>
transformers>=0.2 && <0.5)
rejecting: transformers-0.4.3.0, transformers-0.4.2.0 (conflict:
base==4.10.0.0/installed-4.1..., transformers => base>=2 && <4.9)
rejecting: transformers-0.4.1.0, transformers-0.3.0.0, transformers-0.2.2.1
(conflict: base==4.10.0.0/installed-4.1..., transformers +/-applicativeinbase
=> base>=1.0 && <4.8)
rejecting: transformers-0.2.1.0, transformers-0.2.0.0 (conflict:
base==4.10.0.0/installed-4.1..., transformers +/-applicativeinbase =>
base>=1.0 && <4.3)
rejecting: transformers-0.1.4.0, transformers-0.1.3.0, transformers-0.1.1.0,
transformers-0.1.0.1, transformers-0.0.1.0, transformers-0.0.0.0,
transformers-0.5.3.1, transformers-0.5.3.0, transformers-0.5.0.2 (conflict:
profunctors => transformers>=0.2 && <0.5)
rejecting: transformers-0.4.0.0 (conflict: base==4.10.0.0/installed-4.1...,
transformers +/-applicativeinbase => base>=1.0 && <4.8)
rejecting: transformers-0.2.2.0 (conflict: base==4.10.0.0/installed-4.1...,
transformers +/-applicativeinbase => base>=1.0 && <4.6)
rejecting: transformers-0.1.0.0 (conflict: profunctors => transformers>=0.2 &&
<0.5)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: transformers, contravariant, base,
thorn

After:

$ cabal install --dry-run --index-state=2018-01-04T21:05:55Z thorn
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: thorn-0.2 (user goal)
[__1] next goal: contravariant (dependency of thorn)
[__1] rejecting: contravariant-1.4, contravariant-1.3.3, contravariant-1.3.2,
contravariant-1.3.1.1, contravariant-1.3.1, contravariant-1.3,
contravariant-1.2.2.1, contravariant-1.2.2, contravariant-1.2.1,
contravariant-1.2.0.1, contravariant-1.2, contravariant-1.1, contravariant-1.0
(conflict: thorn => contravariant<1)
[__1] trying: contravariant-0.6.1.1
[__2] next goal: transformers (dependency of contravariant)
[__2] rejecting: transformers-0.5.2.0/installed-0.5..., transformers-0.5.5.0,
transformers-0.5.4.0, transformers-0.5.2.0, transformers-0.5.1.0,
transformers-0.5.0.1, transformers-0.5.0.0 (conflict: contravariant =>
transformers>=0.2 && <0.5)
[__2] trying: transformers-0.4.3.0
[__3] next goal: base (dependency of thorn)
[__3] rejecting: base-4.10.0.0/installed-4.1... (conflict: transformers =>
base>=2 && <4.9)
[__3] rejecting: base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0,
base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1,
base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0,
base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2,
base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2,
base-3.0.3.1 (constraint from non-upgradeable package requires installed
instance)
After searching the rest of the dependency tree exhaustively, these were the
goals I've had most trouble fulfilling: transformers, contravariant, base,
thorn

Differences:

- The new summary has level numbers, like the full log.
- The conflicts are different.  The old log mentions thorn, base, profunctors,
  and transformers, and the new log mentions the four packages from the conflict
  set: thorn, contravariant, transformers, and base.
- The new log starts with the solver choosing a user goal, thorn.

The solver continues to display the conflicts at the first backjump when it
reaches the backjump limit, i.e, it shows profunctors instead of contravariant:

Before:

$ cabal install --dry-run --index-state=2018-01-04T21:05:55Z thorn --max-backjumps=10
Resolving dependencies...
cabal: Could not resolve dependencies:
trying: base-4.10.0.0/installed-4.1... (dependency of thorn)
next goal: profunctors (dependency of thorn)
rejecting: profunctors-5.2.1, profunctors-5.2, profunctors-5.1.2,
profunctors-5.1.1, profunctors-5.1, profunctors-5.0.1, profunctors-5.0.0.1,
profunctors-5 (conflict: thorn => profunctors<5)
trying: profunctors-4.4.1
next goal: transformers (dependency of profunctors)
rejecting: transformers-0.5.2.0/installed-0.5..., transformers-0.5.5.0,
transformers-0.5.4.0, transformers-0.5.2.0, transformers-0.5.1.0,
transformers-0.5.0.1, transformers-0.5.0.0 (conflict: profunctors =>
transformers>=0.2 && <0.5)
rejecting: transformers-0.4.3.0, transformers-0.4.2.0 (conflict:
base==4.10.0.0/installed-4.1..., transformers => base>=2 && <4.9)
rejecting: transformers-0.4.1.0, transformers-0.3.0.0, transformers-0.2.2.1
(conflict: base==4.10.0.0/installed-4.1..., transformers +/-applicativeinbase
=> base>=1.0 && <4.8)
rejecting: transformers-0.2.1.0, transformers-0.2.0.0 (conflict:
base==4.10.0.0/installed-4.1..., transformers +/-applicativeinbase =>
base>=1.0 && <4.3)
rejecting: transformers-0.1.4.0, transformers-0.1.3.0, transformers-0.1.1.0,
transformers-0.1.0.1, transformers-0.0.1.0, transformers-0.0.0.0,
transformers-0.5.3.1, transformers-0.5.3.0, transformers-0.5.0.2 (conflict:
profunctors => transformers>=0.2 && <0.5)
rejecting: transformers-0.4.0.0 (conflict: base==4.10.0.0/installed-4.1...,
transformers +/-applicativeinbase => base>=1.0 && <4.8)
rejecting: transformers-0.2.2.0 (conflict: base==4.10.0.0/installed-4.1...,
transformers +/-applicativeinbase => base>=1.0 && <4.6)
rejecting: transformers-0.1.0.0 (conflict: profunctors => transformers>=0.2 &&
<0.5)
Backjump limit reached (currently 10, change with --max-backjumps or try to
run with --reorder-goals).

After:

$ cabal install --dry-run --index-state=2018-01-04T21:05:55Z thorn --max-backjumps=10
Resolving dependencies...
cabal: Could not resolve dependencies:
[__0] trying: thorn-0.2 (user goal)
[__1] next goal: profunctors (dependency of thorn)
[__1] rejecting: profunctors-5.2.1, profunctors-5.2, profunctors-5.1.2,
profunctors-5.1.1, profunctors-5.1, profunctors-5.0.1, profunctors-5.0.0.1,
profunctors-5 (conflict: thorn => profunctors<5)
[__1] trying: profunctors-4.4.1
[__2] next goal: transformers (dependency of profunctors)
[__2] rejecting: transformers-0.5.2.0/installed-0.5..., transformers-0.5.5.0,
transformers-0.5.4.0, transformers-0.5.2.0, transformers-0.5.1.0,
transformers-0.5.0.1, transformers-0.5.0.0 (conflict: profunctors =>
transformers>=0.2 && <0.5)
[__2] trying: transformers-0.4.3.0
[__3] next goal: base (dependency of thorn)
[__3] rejecting: base-4.10.0.0/installed-4.1... (conflict: transformers =>
base>=2 && <4.9)
[__3] rejecting: base-4.10.1.0, base-4.10.0.0, base-4.9.1.0, base-4.9.0.0,
base-4.8.2.0, base-4.8.1.0, base-4.8.0.0, base-4.7.0.2, base-4.7.0.1,
base-4.7.0.0, base-4.6.0.1, base-4.6.0.0, base-4.5.1.0, base-4.5.0.0,
base-4.4.1.0, base-4.4.0.0, base-4.3.1.0, base-4.3.0.0, base-4.2.0.2,
base-4.2.0.1, base-4.2.0.0, base-4.1.0.0, base-4.0.0.0, base-3.0.3.2,
base-3.0.3.1 (constraint from non-upgradeable package requires installed
instance)
Backjump limit reached (currently 10, change with --max-backjumps or try to
run with --reorder-goals).

One downside of this change is that the solver may reach the backjump limit when
generating the summarized log, if the backjump limit is very low:

$ cabal install --dry-run --index-state=2018-01-04T21:05:55Z thorn --max-backjumps=1
Resolving dependencies...
cabal: Backjump limit reached (currently 1, change with --max-backjumps or try
to run with --reorder-goals).
Failed to generate a summarized dependency solver log due to low backjump
limit.

Another downside is the performance impact of rerunning the solver.  It looks
like there isn't a big change in run time when the solver finds a solution or
fails after an exhaustive search.  However, rerunning the solver to the first
backjump after it reaches the backjump limit can take a significant amount of
time.  The worst case I could find was acme-everything with GHC 7.10.3, where
that step took 13 seconds.  The difference was normally small, though.

I ran hackage-benchmark on packages from Hackage to try to find packages where
the run time changed by more than a few percent.  I stopped it after all
packages starting with "b" (That includes all uppercase packages).

compiler: GHC 8.2.1
index state: 2018-01-04T21:05:55Z
parameters: --min-run-time-percentage-difference-to-rerun=1 --pvalue=0.01 --trials=20 --print-skipped-packages

Out of 2219 packages, 1064 were skipped because the run times in the first trial
were within 1%, 1065 differed by more than 1% in the first trial but did not
show a significant difference in run time in 20 trials, and 90 did show a
significant difference in run time.  Here are the counts of packages for
different ranges of speedup, for those 90 packages:

speedup (master avg. run time / branch avg. run time)     package count
[0.93, 0.94)                                              1
[0.94, 0.95)                                              0
[0.95, 0.96)                                              0
[0.96, 0.97)                                              1
[0.97, 0.98)                                              7
[0.98, 0.99)                                              29
[0.99, 1.00)                                              47
[1.00, 1.01)                                              3
[1.01, 1.02)                                              2

The package with the biggest percentage change was bittorrent, which ran for
3.85 seconds on master and 4.12 seconds on this branch.  It reached the backjump
limit.

5d3618a1

Sep 28, 2017

Make Backpack work with profiling. · 628c396f

Edward Z. Yang authored 7 years ago


I am not sure what I was thinking when I modified the
code to skip profiling builds if there was no code,
but this is surely wrong!  Comes with a test.

Fixes #4754.

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

628c396f

Sep 25, 2017

Remove the package instance from D.Solver.Modular.Var (closes #4142). · e1ca9dcf

kristenk authored 7 years ago

This change has several effects:

- The solver no longer includes the package version in messages that relate to
  a package's flags, stanzas, or dependencies.  However, the solver always
  chooses the package version before choosing any flags, stanzas, or
  dependencies for the package, so it should be easy to find the version
  by looking earlier in the log.
- In conflict counting, the solver treats flags with the same name in different
  versions of a package as the same flag.  This change in the conflict counting
  heuristic can improve the solver's efficiency when the same flag causes the
  same conflicts in different versions of a package.  The same applies to
  enabling tests or benchmarks.
- Each flag or stanza can only appear once in a conflict set.  This has no
  effect on behavior, but it simplifies the message containing the final
  conflict set.

Here is an example of the change in a log message.  It only prints
hackage-server's version once, when it first chooses the package.  The conflict
set also has one fewer variable, but that is probably due to the change in
conflict counting.

 Resolving dependencies...
 cabal: Could not resolve dependencies:
 trying: hackage-server-0.5.0 (user goal)
-trying: hackage-server-0.5.0:+build-hackage-build
-trying: unix-2.7.2.1/installed-2.7... (dependency of hackage-server-0.5.0
+trying: hackage-server:+build-hackage-build
+trying: unix-2.7.2.1/installed-2.7... (dependency of hackage-server
 +build-hackage-build)
-next goal: aeson (dependency of hackage-server-0.5.0 +build-hackage-build)
+next goal: aeson (dependency of hackage-server +build-hackage-build)
 rejecting: aeson-1.2.2.0, aeson-1.2.1.0, aeson-1.2.0.0, aeson-1.1.2.0,
 aeson-1.1.1.0, aeson-1.1.0.0, aeson-1.0.2.1, aeson-1.0.2.0, aeson-1.0.1.0,
 aeson-1.0.0.0, aeson-0.11.3.0, aeson-0.11.2.1, aeson-0.11.2.0, aeson-0.11.1.4,
 aeson-0.11.1.3, aeson-0.11.1.2, aeson-0.11.1.1, aeson-0.11.1.0,
 aeson-0.11.0.0, aeson-0.9.0.1, aeson-0.9.0.0, aeson-0.8.1.1, aeson-0.8.1.0,
 aeson-0.8.0.2, aeson-0.7.0.6, aeson-0.7.0.4, aeson-0.6.2.1, aeson-0.6.2.0
 (conflict: hackage-server +build-hackage-build => aeson==0.6.1.*)
 rejecting: aeson-0.6.1.0 (conflict: unix => time==1.6.0.1/installed-1.6...,
 aeson => time<1.5)
 rejecting: aeson-0.6.0.2, aeson-0.6.0.1, aeson-0.6.0.0, aeson-0.5.0.0,
 aeson-0.4.0.1, aeson-0.4.0.0, aeson-0.3.2.14, aeson-0.3.2.13, aeson-0.3.2.12,
 aeson-0.3.2.11, aeson-0.3.2.10, aeson-0.3.2.9, aeson-0.3.2.8, aeson-0.3.2.7,
 aeson-0.3.2.6, aeson-0.3.2.5, aeson-0.3.2.4, aeson-0.3.2.3, aeson-0.3.2.2,
 aeson-0.3.2.1, aeson-0.3.2.0, aeson-0.3.1.1, aeson-0.3.1.0, aeson-0.3.0.0,
 aeson-0.2.0.0, aeson-0.1.0.0, aeson-0.10.0.0, aeson-0.8.0.1, aeson-0.8.0.0,
 aeson-0.7.0.5, aeson-0.7.0.3, aeson-0.7.0.2, aeson-0.7.0.1, aeson-0.7.0.0
 (conflict: hackage-server +build-hackage-build => aeson==0.6.1.*)
 After searching the rest of the dependency tree exhaustively, these were the
-goals I've had most trouble fulfilling: aeson, hackage-server,
-hackage-server-0.5.0:build-hackage-build,
-hackage-server-0.4:build-hackage-mirror, template-haskell
+goals I've had most trouble fulfilling: aeson,
+hackage-server:build-hackage-build, hackage-server, template-haskell

I ran hackage-benchmark to compare this commit with master (two commits
earlier).  I used --min-run-time-percentage-difference-to-rerun=10 to only rerun
packages if the run times differed by more than 10% in the first trial, and
defaults for the rest of the options (10 trials, p-value of 0.05, 90 second
timeout). The index state was "2017-09-24T03:35:06Z".

1 is master, and 2 is this commit:

package            result1       result2             mean1       mean2     stddev1     stddev2     speedup
CC-delcont-ref     Solution      Solution           1.467s      1.505s      0.019s      0.100s      0.975
ascii-cows         Solution      Solution           1.827s      1.758s      0.159s      0.012s      1.040
opaleye-classy     NoInstallPlan NoInstallPlan      4.588s      4.070s      0.043s      0.032s      1.127
range-space        NoInstallPlan NoInstallPlan      2.642s      2.299s      0.016s      0.016s      1.149
rts                PkgNotFound   PkgNotFound        1.323s      1.327s      0.032s      0.033s      0.997
servant-auth-docs  Solution      Solution           1.968s      1.998s      0.017s      0.074s      0.985
thorn              BackjumpLimit NoInstallPlan      4.793s      3.141s      0.050s      0.034s      1.526
unordered-intmap   Solution      Solution           1.502s      1.511s      0.081s      0.047s      0.994

I looked at the solver logs for the three packages with the largest changes in
run time, opaleye-classy, range-space, and thorn.  Each one showed that the
solver started preferring a flag in an older version of a package after it had
caused conflicts in a newer version of the package.

e1ca9dcf

Aug 10, 2017

Add missing separator in solver fallback message · 08a7754e

tuncer authored 7 years ago

Without this it would print a list of packages and append
  "Trying configure anyway."
without any separator between the list and the new sentence.

08a7754e

Jul 21, 2017
- Further compact build profile output in new-build · 36861e43
  Amir Mohammad Saied authored 7 years ago
  
  36861e43
Jul 18, 2017
- Test suite: --accept more stuff. · 2b8cb2c2
  Mikhail Glushenkov authored 7 years ago
  
  Unverified
  
  2b8cb2c2
Jul 16, 2017
- Update test fixtures to reflect new-build changes · 13207c9b
  Amir Mohammad Saied authored 7 years ago
  
  13207c9b
Jul 10, 2017

Fix bug in conflict counting. · 22d44325

kristenk authored 7 years ago

In Explore.hs, the solver calculates a conflict set corresponding to the option
to not choose a value for each goal, called 'initial'. That conflict set should
be added to the ConflictMap when the current goal causes a conflict. However,
there was a bug, and the solver added 'initial' to the ConflictMap at every
level.

The bug meant that the solver preferred all goals that it had already chosen.
If a new goal started to cause conflicts, it would take a while for the solver
to start preferring the new goal over the ones that it had previously seen.
See #4595 for an example where this problem caused longer backjumps and slowed
down the solver.

Testing

I ran "cabal install --dry-run" for all packages on Hackage with master and the branch with a 90 second timeout, GHC 8.0.1, and index state 2017-07-08T04:20:18Z. Then I filtered out all packages where both runs had the same result (success or failure) and the times were within 10%. I repeated that process three times to eliminate packages that had different run times due to noise. Then I ran "cabal install --dry-run --max-backjumps=-1" on the remaining packages and averaged three runs.

Since this branch changes a goal-ordering heuristic, I expected a lot of changes in run time in either direction. Out of 105 changes, 83 were faster, 20 were slower, and 2 involved a timeout on both branches. (The two that timed out had different run times before I removed the backjump limit.)

package master result master time (seconds) branch result branch time (seconds) speedup
AesonBson solution 3.06 solution 2.59 1.18
DisTract no solution 1.48 no solution 1.34 1.1
GPipe-Examples timeout 90.01 no solution 2.11 -
GuiTV solution 2.54 solution 16.05 0.16
Phsu solution 3.49 solution 1.83 1.9
Ranka no solution 2.05 no solution 1.65 1.25
Rlang-QQ no solution 2.97 no solution 1.89 1.57
SourceGraph timeout 90.04 no solution 11.53 -
Validation no solution 2.1 no solution 6.59 0.32
WebCont no solution 2.04 no solution 1.6 1.28
acme-everything timeout 90.02 timeout 90 -
aeson-t solution 2.04 solution 1.81 1.13
alsa-gui no solution 1.62 no solution 1.86 0.87
aviation-cessna172-diagrams no solution 2.56 no solution 2.29 1.12
aws-dynamodb-conduit no solution 2.22 no solution 1.83 1.22
azure-servicebus no solution 5.18 no solution 2.87 1.8
bamboo-theme-mini-html5 no solution 2.51 no solution 2 1.26
bitcoin-payment-channel solution 3.42 solution 2.73 1.25
bittorrent no solution 2.75 no solution 2.4 1.15
blaze-builder-enumerator no solution 1.62 no solution 1.88 0.86
blunt solution 2.99 solution 2.5 1.19
cash no solution 1.33 no solution 1.53 0.87
cheapskate-terminal no solution 2.04 no solution 1.62 1.26
clckwrks-plugin-bugs no solution 3.85 no solution 5.78 0.67
cmdtheline no solution 1.96 no solution 1.63 1.2
colchis no solution 1.99 no solution 2.23 0.89
collada-types no solution 1.86 no solution 1.66 1.12
convertible-text solution 1.61 solution 1.83 0.88
cqrs-example no solution 2.64 no solution 2.32 1.14
dixi solution 4.44 solution 4.03 1.1
ethereum-client-haskell no solution 1.84 no solution 2.45 0.75
flowdock no solution 2.46 no solution 3.19 0.77
geniserver no solution 5.34 no solution 4.84 1.1
ghc-imported-from solution 4.59 solution 2.9 1.58
gps2htmlReport solution 3.08 solution 5.58 0.55
guarded-rewriting solution 1.54 solution 1.34 1.14
hack2-handler-happstack-server no solution 1.76 no solution 2 0.88
halma-telegram-bot solution 4.27 solution 3.37 1.27
happs-tutorial no solution 2.08 no solution 1.86 1.12
happstack no solution 3.08 no solution 5.86 0.53
happstack-facebook timeout 90.01 timeout 90.03 -
haskelldb-hsql-mysql no solution 1.73 no solution 1.5 1.16
hdbi no solution 1.92 no solution 1.66 1.15
hdbi-postgresql no solution 3.05 no solution 1.95 1.56
hdbi-sqlite no solution 1.91 no solution 1.69 1.13
hexpat-iteratee no solution 2.61 no solution 1.84 1.42
hist-pl no solution 2.69 no solution 2.36 1.14
hscd no solution 2.53 no solution 1.59 1.59
http-client-lens no solution 3.63 no solution 1.96 1.85
hubris no solution 3.62 no solution 1.63 2.22
infinity no solution 1.34 no solution 1.5 0.89
iteratee-parsec no solution 2.01 no solution 1.74 1.16
json-togo no solution 1.86 no solution 1.65 1.13
lat no solution 2.87 no solution 1.86 1.55
liquidhaskell solution 3.34 solution 2.25 1.48
manatee-core no solution 1.79 no solution 1.6 1.12
manatee-curl no solution 8.44 no solution 2.73 3.09
manatee-editor no solution 5.05 no solution 2.81 1.8
manatee-filemanager no solution 29.09 no solution 2.96 9.82
manatee-imageviewer no solution 1.78 no solution 1.57 1.13
manatee-mplayer no solution 8.98 no solution 4.05 2.22
manatee-terminal no solution 3.19 no solution 2.41 1.32
minimung no solution 1.86 no solution 1.57 1.19
monoids no solution 3.02 no solution 2.68 1.13
mprover no solution 1.89 no solution 1.54 1.23
ms no solution 8.04 no solution 4.35 1.85
music-sibelius solution 3.1 solution 2.5 1.24
nerf solution 22.54 solution 3.09 7.29
nomyx-api solution 5.46 solution 4.39 1.24
nomyx-library solution 2.08 solution 1.86 1.11
nomyx-server no solution 4.83 no solution 3.92 1.23
opaleye-classy no solution 2.07 no solution 3.58 0.58
openflow no solution 1.95 no solution 1.66 1.18
ot no solution 3.37 no solution 1.95 1.73
paypal-api no solution 1.89 no solution 1.64 1.15
pdf-slave-server no solution 3.21 no solution 2.15 1.49
phooey solution 2.55 solution 16.24 0.16
pipes-cereal-plus solution 1.85 solution 1.65 1.12
pocket-dns no solution 2.71 no solution 2.08 1.3
pontarius-mediaserver no solution 2.29 no solution 2.7 0.85
precis no solution 2.53 no solution 3.23 0.78
prove-everywhere-server no solution 2.19 no solution 1.92 1.14
quickbooks no solution 5.86 no solution 5.17 1.13
rbpcp-api solution 2.35 solution 2.13 1.11
react-haskell timeout 90.02 no solution 71.21 -
regex-xmlschema no solution 1.34 no solution 1.51 0.89
remote-json-server solution 2.1 solution 1.8 1.16
scholdoc-citeproc no solution 3 no solution 1.92 1.57
scion-browser no solution 5.21 no solution 4.65 1.12
semdoc no solution 4.21 no solution 3.04 1.39
servant-auth-token-rocksdb no solution 4.68 no solution 2.32 2.02
snaplet-auth-acid no solution 2.25 no solution 1.99 1.13
snaplet-stripe no solution 3.46 no solution 2.97 1.16
sssp no solution 3.3 no solution 2.79 1.18
target solution 2.8 solution 2.11 1.32
tls-extra no solution 2.74 no solution 2.36 1.16
twentefp-rosetree no solution 1.69 no solution 1.97 0.86
twitter-enumerator no solution 28.39 no solution 2.16 13.15
wai-middleware-cache no solution 1.95 no solution 1.56 1.25
wai-middleware-catch no solution 1.9 no solution 1.54 1.24
wai-middleware-route solution 11.9 solution 1.62 7.34
xml2json no solution 2.27 no solution 1.68 1.35
yesod-auth-account-fork solution 3.33 solution 2.87 1.16
yesod-comments no solution 25.6 no solution 14.44 1.77
yesod-pure solution 7.99 solution 4.45 1.79

22d44325

Jun 06, 2017

Fix test suite wobbliness on GHC 8.2. · b5d1e190

Edward Z. Yang authored 7 years ago


Here were the root causes:

- Some tests involving Custom setpu showed MORE output
  (UseLocalPackageForSetup) when run on GHC 8.2.  This is because GHC
  8.2 ships a recent enough version of Cabal to know how to emit
  markers, which means we have started picking up the output.  I hacked
  up these tests to not accept this output, but a more correct thing to
  do is figure out how to NOT request marking of a Setup script which is
  not the inplace install.  This was a little tricky so I bailed.

- GHC 8.2 no longer emits "It is a member of the hidden package".
  This broke CustomWithoutCabalDefaultMain.  Not sure if this
  is a GHC regression but it's pretty harmless.

- While I was at it, I fixed an inexhaustive pattern match in
  cabal-testsuite (though perhaps poorly; I couldn't figure out
  what the new constructor does.)

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

b5d1e190

Apr 24, 2017

Implement pre-mixin-linking, make local modules participate. · 65f671a1

Edward Z. Yang authored 7 years ago


A few things:

- We now have a proper pre-mixin-linking pass which computes
  just the set of requirements we expect to see after mixin
  linking is done.  That lets us precompute the unit id
  for locally defined modules.

- Since we now know the correct module identities, we can
  make shapes for exposed-modules/other-modules and make
  them participate in mix-in linking.

- But we don't actually want to instantiate a requirement with
  a locally defined module, because GHC can't compile that!
  We want to error in this case.  Previously, we didn't notice
  that this had occurred at all; now it is caught, fixing #4447.

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

65f671a1

Mar 26, 2017

Tweak target selection semantics for indefinite packages. · 4378f5c2

Edward Z. Yang authored 8 years ago


Suppose you have a Backpack package foo-indef, which has
some signatures; furthermore, elsewhere in your install plan
ths packages gets instantiated. When you type
'cabal new-build foo-indef', what should get built?

Previously: foo-indef, as well as all of its instantiations,
get built.

Now: only the indefinite foo-indef is typechecked.

This is what you want!

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

4378f5c2

Mar 17, 2017

Bugfixes for Backpack error reporting. · 8c5511e1

Edward Z. Yang authored 8 years ago


* Propagate ComponentName to ModuleSource, allowing
  us to accurately specify both package and library name
  of references.  (Arguably, should just stuff a ComponentInclude
  in there.)

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

8c5511e1

Fix Backpack test drift (since it's not CI'd) · e663b525
Edward Z. Yang authored 8 years ago
```
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
```
e663b525

Mar 01, 2017

Don't specify hs-libraries when none exists! · 9d821594

Edward Z. Yang authored 8 years ago

This fixes GHC bug
https://ghc.haskell.org/trac/ghc/ticket/13268



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

9d821594

Feb 19, 2017

Expect tests for cabal-testsuite. · 2ea28cab

Edward Z. Yang authored 8 years ago and

Edward Z. Yang committed 8 years ago


- We switched to using regex-tdfa, as regex-posix is buggy on Windows.

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

2ea28cab

Add missing default-languages · 4924762d
Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago
```
Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
```
4924762d

Add context to error messages. · de2c80cb

Edward Z. Yang authored 8 years ago and

Edward Z. Yang committed 8 years ago


New output:

Error:
    Problem with module re-exports:
      - The module 'Asdf'
        is not exported by any suitable package.
        It occurs in neither the 'exposed-modules' of this package,
        nor any of its 'build-depends' dependencies.
    In the stanza 'library'
    In the inplace package 'Reexport2-1.0'

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

de2c80cb

Dec 13, 2016
- Report an error if a non-library has unfilled requirements. · 14b50f3c
  Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago
  
  Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
  14b50f3c
- Report error if mixin refers to non-existent/visible package. · 542789ea
  Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago
  
  Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
  542789ea
- Report an error if you rename a requirement that doesn't exist. · 56688d70
  Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago
  
  Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
  56688d70
- Don't require base for implicitly generated signatures. · 34187136
  Edward Z. Yang authored 8 years ago and Edward Z. Yang committed 8 years ago
  
  Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
  34187136
Nov 27, 2016
- Port backpack/includes3 to new test suite. · 7b90a216
  Edward Z. Yang authored 8 years ago
  
  Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
  7b90a216
- Port backpack/includes2 to new test suite. · e309598e
  Edward Z. Yang authored 8 years ago
  
  Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
  e309598e
Nov 18, 2016

Rewrite the test suite, AGAIN. (#4095) · e496b09e

Edward Z. Yang authored 8 years ago


See cabal-testsuite/README.md for a detailed description
of the new architecture.

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

e496b09e

Oct 31, 2016

Move PackageTests to new cabal-testsuite package. · a6d2ec3e

Edward Z. Yang authored 8 years ago and

Edward Z. Yang committed 8 years ago

The key idea is that once we put PackageTests in its own package, we can
ensure that its Setup.hs is compiled with the same version of Cabal
library as package-tests is compiled with. This means that LBI reading
will *always succeed* which is quite nice.

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

a6d2ec3e