Don't persist failure to the database

[ndmitchell]

Currently I store failures in the database by marking them explicitly as missing. I see no reason for storing failures since it defeats previous value equality and this can cause huge rebuilds even if nothing changes.

[ndmitchell]

Note that you have to conservatively assume that failures aren't in the DB since the "failure" might be kill -9 while rebuilding. That's another point in favour of not recording failures explicitly.

This issue is also discussed at haskell/cabal#3179.

[Mathnerd314]

Let's say the failure is due to a syntax error. In this case, rebuilding is futile until the input files change. Persisting failures (in a structure similar to Result) would stop further builds until the offending syntax is fixed, which would be useful for continuous recompilation (#371).

ShakeException would need to be serializable; would anything be lost with shakeExceptionInner :: String?

[ndmitchell]

Often the failures are due to untracked assumptions, e.g. ghc version, and rebuilding without changing the input files is desirable. I imagine for continuous recompilation you'd want to wait until something relevant changed, so there you have no need to serialise something like ShakeException - you only care if something relevant changed, not what the last result was.

[ndmitchell]

Now implemented, note that this changes the invariants. Previously if you had a rule which claimed to produce foo, but also (secretly from Shake) produced bar, then you could write:

rm bar
need [my-dependency]
touch bar
touch foo

And this would work. There was an invariant that if you ever start running a rule then that rule is dirty until the rule has completed. Now, if the child ends up in an erroneous state, the parent might be started, cancelled, then skipped. Certainly a corner case, so hopefully nothing anyone ever wanders in to.