From 9b90488efda0853c2d511a0224be77764ce8cb31 Mon Sep 17 00:00:00 2001
From: "Paolo G. Giarrusso"
Date: Wed, 17 Aug 2016 10:22:37 +0200
Subject: [PATCH] solver: parse cabal errors also on Windows
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
As shown in #2502, `cabal init --solver` can fail with `Could not parse
cabal-install errors` on Windows. The problem boils down to the fact that
we test `isSuffixOf "suffix" "stuff suffix\r"`, which is false, so we
should better strip `\r` before calling `isSuffixOf`.
I've verified that `\r` is actually there only indirectly; I inferred it
from the presence of `stripCR` and the parse failure, and I've recently
seen the behavior of lines on strings with Windows line ends.
Testing confirms this PR fixes the bug—the original procedure fails with
the parent commit and works with this one.
---
src/Stack/Solver.hs | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/Stack/Solver.hs b/src/Stack/Solver.hs
index 4aba9391a3..7757837096 100644
--- a/src/Stack/Solver.hs
+++ b/src/Stack/Solver.hs
@@ -136,6 +136,7 @@ cabalSolver menv cabalfps constraintType
where
errCheck = T.isInfixOf "Could not resolve dependencies"
+ linesNoCR = map stripCR . T.lines
cabalBuildErrMsg e =
">>>> Cabal errors begin\n"
<> e
@@ -167,7 +168,7 @@ cabalSolver menv cabalfps constraintType
else errExit msg
parseConflictingPkgs msg =
- let ls = dropWhile (not . errCheck) $ T.lines msg
+ let ls = dropWhile (not . errCheck) $ linesNoCR msg
select s = ((T.isPrefixOf "trying:" s)
|| (T.isPrefixOf "next goal:" s))
&& (T.isSuffixOf "(user goal)" s)
@@ -180,8 +181,7 @@ cabalSolver menv cabalfps constraintType
parseCabalOutput bs = do
let ls = drop 1
$ dropWhile (not . T.isPrefixOf "In order, ")
- $ map stripCR
- $ T.lines
+ $ linesNoCR
$ decodeUtf8 bs
(errs, pairs) = partitionEithers $ map parseCabalOutputLine ls
if null errs