Stack: `stack test` doesn't rebuild test correctly

[joncol]

Summary

stack test doesn't seem to rebuild test correctly.

Steps to reproduce

I've created a minimal repository to demonstrate this. It can be found at https://github.com/joncol/Broken.

The test as it is, is broken by design.

1. Run command stack build.
2. Run command stack test. It should fail.
3. To fix the failing test, change line 19 of src/Broken.hs to: mempty = BoolConj True
4. Run command stack test.

Expected

The test should work.

Actual

No change, the test still fails. But when running stack clean followed by stack test, it succeeds.

Stack version

$ stack --version
Version 1.2.0 x86_64 hpack-0.14.0

Method of installation

Official binary, downloaded from stackage.org or fpcomplete's package repository

[mgsloan]

Wow, that's quite a bug, thanks for the report with repro!

[mgsloan]

This one is a real mystery! Switching Cabal versions doesn't seem to resolve it, but the code is getting built and a new executable is created. Very, very strange!

[mgsloan]

It seems like this must be some bizarre GHC bug. It is very strange! If I add someInt = 1 to the library, and print ("test", someInt) to the test, modifying it does indeed always cause different output. Modifying it at the same time as modifying the definition of mempty causes things to behave as expected.

If it is a GHC bug, then it is one that's been around for a while, since at least 7.8. On one hand it's hard to believe an issue like this would go undetected, and I have no clue what the mechanism would be. On the other hand, GHC is the only thing that would care about the difference between modifying an instance and modifying a top level function.

[Blaisorblade]

Just to be sure, has somebody tried reproducing this with cabal-install, just to confirm the bug is not stack-specific somehow? I'd be curious to see the verbose log...

[snoyberg]

Some reports:

1. I was able to reproduce with recent Stack master
2. I tested with plain ghc, and the problem did _not_ present
3. I bumped to nightly-2017-10-22, which includes GHC 8.2.1 and Cabal 2.0, and was _still_ able to reproduce
4. I then tested with cabal, and _also_ got the same bug.

So I'm pretty sure this is coming from the Cabal layer, though I have no idea what would be triggering it. Knocking this down to something more minimal and then submitting upstream would be a good next step.

[silky]

i mean ...

this is still happening?!?!?!

stack --version
Version 2.3.2, Git revision cda9351495caf7cfdb8ecfc5011b22336454967c RELEASE-CANDIDATE x86_64 hpack-0.33.0

has no-one tested haskell code in 3 years?

hahaha :)