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