-
Notifications
You must be signed in to change notification settings - Fork 841
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
"stack repl <test suite>" fails if "stack test --no-run-tests" is not run in advance for test suite containing errors #5380
Comments
Hey @runeksvendsen - sorry for the delayed response. When I follow your steps above ...
[ 9 of 12] Compiling Digraph.Spec
/apps/apps/stack-issues/i5380/test/Digraph/Spec.hs:47:22: error:
• Couldn't match type ‘TestEdge’ with ‘Lib.IdxEdge String Double’
Expected type: TestEdge -> IO ()
Actual type: Lib.IdxEdge String Double -> IO ()
• In the second argument of ‘forM_’, namely
‘(stToIO . Lib.removeEdge graph)’
In a stmt of a 'do' block:
forM_ edges (stToIO . Lib.removeEdge graph)
In the expression:
do graph <- stToIO $ Lib.fromEdges edges
forM_ edges (stToIO . Lib.removeEdge graph)
vertices <- stToIO $ Lib.vertices graph
return (graph, vertices)
|
47 | forM_ edges (stToIO . Lib.removeEdge graph)
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
/apps/apps/stack-issues/i5380/test/Digraph/Spec.hs:62:44: error:
• Couldn't match type ‘edge’ with ‘TestEdge’
‘edge’ is a rigid type variable bound by
the type signature for:
addEdgesCheckInOutgoing :: forall edge.
(Lib.Digraph RealWorld String Double
-> Lib.VertexId -> IO [edge])
-> [TestEdge] -> Expectation
at test/Digraph/Spec.hs:(51,1)-(54,18)
Expected type: [edge]
Actual type: [TestEdge]
• In the second argument of ‘shouldBe’, namely
‘removeDuplicateSrcDst sortedEdges’
In a stmt of a 'do' block:
sort (concat outgoingEdges)
`shouldBe` removeDuplicateSrcDst sortedEdges
In the expression:
do let sortedEdges = sort edges
graph <- stToIO $ Lib.fromEdges (reverse sortedEdges)
vertices <- stToIO $ Lib.vertices graph
outgoingEdges <- foldM (collectInOutgoing graph) [] vertices
....
• Relevant bindings include
outgoingEdges :: [[edge]] (bound at test/Digraph/Spec.hs:61:5)
collectInOutgoing :: Lib.Digraph RealWorld String Double
-> [[edge]] -> Lib.VertexId -> IO [[edge]]
(bound at test/Digraph/Spec.hs:64:5)
inOutEdges :: Lib.Digraph RealWorld String Double
-> Lib.VertexId -> IO [edge]
(bound at test/Digraph/Spec.hs:55:25)
addEdgesCheckInOutgoing :: (Lib.Digraph RealWorld String Double
-> Lib.VertexId -> IO [edge])
-> [TestEdge] -> Expectation
(bound at test/Digraph/Spec.hs:55:1)
|
62 | sort (concat outgoingEdges) `shouldBe` removeDuplicateSrcDst sortedEdges
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
-- While building package bellman-ford-0.1.0.0 using:
/usr/home/matt/.stack/setup-exe-cache/x86_64-freebsd-ino64/Cabal-simple_mPHDZzAJ_2.4.0.1_ghc-8.6.5 --builddir=.stack-work/dist/x86_64-freebsd-ino64/Cabal-2.4.0.1 build lib:bellman-ford test:bellman-ford-tes
t --ghc-options " -fdiagnostics-color=always"
Process exited with code: ExitFailure 1
Progress 1/2
The same steps (including Is it possible this is a fluke or am I missing something? Thanks for reporting in any case. |
Hi @mattaudesse Thank you for getting back to me. No worries about the delay. The crux of this bug report is as follows. If I do the following:
Then the If, however, I do the following (ie. omit
Then the I would think that the success of running The reason I report this as a bug is because it causes a problem when stack is used in combination with |
Thanks for the extra info - that helps. I've tagged this as a bug but also "for discussion" since I could see it posing some architectural questions about what should happen in this case + how. |
Seems like this is related to #1406. The comment here seems to describe this bug perfectly: #1406 (comment). |
@runeksvendsen from my quick glance it looks like this problem could be another case for #4745 but I didn't have time yet to look closer into it. |
Thank you for looking into this. What makes you think the two are related? Would fixing #4745 get rid of the error described in #1406 (comment)? |
Yes, component-based builds seems to be exactly what's needed in that situation - currently Stack builds all the components at once with an option to enable/disable tests/benchmarks. |
This looks quite similar to #5213 (first |
It's very similar, but there's a difference in that this fix seems to no longer work if there's a compilation error in the test suite. If there is a compilation error in the test suite then |
hi, is there some chance to have some progresss on this? hls+stack users are reporting this frequently, thanks! |
Unfortunately it looks like the work on component-based builds has stalled and there seem to be no budget for this or new volunteers :( |
@qrilka thanks for the update. I want to note that i think the inclusion of |
Thanks for sharing the link, I will at least check it out later today. |
Apparently we are still having this issue. Independent of other solutions, as mentioned in #5380 (comment), do we have progress on this issue, or how could we achieve some progress? |
Documenting my own understanding of the problem with the current version of Stack (the corrected release candidate for Stack 2.11.1) and a plain vanilla
results in (ending with a GHCi prompt):
While
results in (ending with GHCi's exit):
|
So, in the first example, the library In the second example, the library At first blush, the different behaviour seems to me to explicable by reference to how GHCi behaves. Is the suggestion that Stack should always go on to install/register a package's library (if built) - even if another part of the build plan for the package fails? |
I think the key part of Stack's code is the realBuild ::
ConfigCache
-> Package
-> Path Abs Dir
-> (KeepOutputOpen -> ExcludeTHLoading -> [String] -> RIO env ())
-> (Utf8Builder -> RIO env ())
-- ^ A plain 'announce' function
-> Map Text ExecutableBuildStatus
-> RIO env Installed
realBuild cache package pkgDir cabal0 announce executableBuildStatuses = do
let cabal = cabal0 CloseOnException
...
() <- announce
( "build"
<> display (annSuffix executableBuildStatuses)
)
...
cabal stripTHLoading (("build" :) $ (++ extraOpts) $ ...
`catch` \ex -> case ex of
CabalExitedUnsuccessfully{} ->
postBuildCheck False >> prettyThrowM ex
_ -> throwM ex
...
when shouldCopy $ withMVar eeInstallLock $ \() -> do
announce "copy/register"
eres <- try $ cabal KeepTHLoading ["copy"]
...
when hasLibrary $ cabal KeepTHLoading ["register"] Stack uses Cabal (the library) to build. If Cabal fails for some reason, an exception is thown and Stack never gets to the actions where Stack uses Cabal to register. I can't see an easy way for Stack to know that Cabal's exception related to a test suite and did not relate to relate to a library. |
For whoever is deciding how much work/budget gets put into Stack/how issues are prioritised: I want to mention that HLS not working smoothly with stack (which this particular components issue is seemingly 90% of the reason why) is by far the #\1 reason why I've currently switched to using cabal. |
General summary/comments
Running the REPL for only the test suite in my project fails with an error saying the library package cannot be satisfied (even though the library builds without errors).Please see #5380 (comment) for an accurate description of the problem (I didn't realize this was the exact problem when I created this issue).
Steps to reproduce
Now start a REPL for the test suite:
Expected
Not failing with a "cannot satisfy -package"-error since the library builds fine.
Actual
It fails with the following error:
Verbose output: https://gist.github.com/runeksvendsen/4ef3125578dc9de82962912be29f2f89
Stack version
Method of installation
stack upgrade
The text was updated successfully, but these errors were encountered: