Another solver puzzle

[phadej]

servant-lucid-0.8 % time cabal new-build -w ghc-7.8.4 --max-backjumps=20000 --enable-tests --dry

[__4] fail (backjumping, conflict set: base, servant-lucid, warp)
Backjump limit reached (currently 20000, change with --max-backjumps or try to
run with --reorder-goals).

cabal new-build -w ghc-7.8.4 --max-backjumps=20000 --enable-tests --dry  45,78s user 0,26s system 100% cpu 45,951 total

reorder goals "helps":

servant-lucid-0.8 % time cabal new-build -w ghc-7.8.4 --max-backjumps=20000 --enable-tests --dry --reorder-goals
cabal new-build -w ghc-7.8.4 --max-backjumps=20000 --enable-tests --dry   88,17s user 0,37s system 100% cpu 1:28,37 total

more backjumps is faster:

servant-lucid-0.8 % time cabal new-build -w ghc-7.8.4 --max-backjumps=30000 --enable-tests --dry
cabal new-build -w ghc-7.8.4 --max-backjumps=30000 --enable-tests --dry  61,28s user 0,30s system 100% cpu 1:01,44 total

Maybe this is the same puzzle as #4976, cc @grayjay.

We know that recent wai ecosystem package versions have dropped GHC-7.8 support (see e.g. https://matrix.hackage.haskell.org/package/warp, https://matrix.hackage.haskell.org/package/resourcet contributes too), and solver's job is harder, as it has to pick older versions (in warp case 7th new atm).

[phadej]

Or it might be related with transformers-compat + resourcet interaction

[sebright]

Yes, this issue looks similar to #4976. I ran the first command using the branch from #4805, and it found a solution in 3.6 seconds. The log still showed a lot of backtracking (conflicts between servant-server, resourcet, wai-extra, wai-app-static, etc.), so there is probably even more room for improvement, possibly by applying #4805 to more types of conflicts.

[sebright]

This issue should be fixed by #5918.