Change in behavior from GHC 7.10.3 to GHC 8.0.1?

[FranklinChen]

Upon upgrade from Stackage LTS 6.x (corresponding to GHC 7.10.3) to 7.0 (corresponding to GHC 8.0.1), tests that used to succeed now fail. A sample repo is here: https://github.com/FranklinChen/should-not-typecheck-example

$ stack test --resolver lts-6

shows that the tests used to pass.

$ stack test

will reproduce the new errors under lts-7.

The errors now:

  test/ShouldNotTypecheckExampleSpec.hs:21:
  1) ShouldNotTypecheckExample.should-not-typecheck you can run code even if it contains ill-typed parts
       uncaught exception: TypeError (src/ShouldNotTypecheckExample.hs:8:28: error:
           • Couldn't match expected type ‘[Char]’ with actual type ‘Bool’
           • In the second argument of ‘(/)’, namely ‘True’
             In the expression: "world" / True
             In the expression: ["world" / True, "!"]
       (deferred type error))

  test/ShouldNotTypecheckExampleSpec.hs:23:
  2) ShouldNotTypecheckExample.should-not-typecheck deferred type errors are only lazily reached
       uncaught exception: TypeError (src/ShouldNotTypecheckExample.hs:14:28: error:
           • Couldn't match expected type ‘[Char]’ with actual type ‘Bool’
           • In the second argument of ‘(/)’, namely ‘True’
             In the expression: "world" / True
             In the expression: ["world" / True, "!"]
       (deferred type error))

[CRogers]

Thanks for reporting, busy this week but will try to find some time.

[FranklinChen]

Any more word on this?

[CRogers]

Seems to work for me on GHC 8.0.1/LTS 7.1.4:

shouldNotCompile
  should not throw an assertion error when an expression is ill typed
  should throw an assertion error when an expression is well typed
  should throw an actual exception and not fail the assertion if the expression contains an non-HUnitFailure exception
  should propagate an actual exception and not fail the assertion if the expression contains a non-deferred ErrorCall exception
  should not throw an assertion when an expression with more than one level of constructors is ill typed
  should warn if an expression had a type error due to lack of NFData instance

Finished in 0.0004 seconds
6 examples, 0 failures

Closing pre-emptively but do tell me if there is still a problem - I have time over xmas to fix it.

[FranklinChen]

It's still not working.

What platform are you running on? This is still reliably failing for me with LTS 7.1.4. See my Travis build on Linux and Mac OS X:

https://travis-ci.org/FranklinChen/should-not-typecheck-example/jobs/185522346

https://travis-ci.org/FranklinChen/should-not-typecheck-example/jobs/185522349

[FranklinChen]

I just realized your test output was not from running my test project (which illustrates something that worked in LTS 6 but not in LTS 7). So we were talking past each other there.

[CRogers]

Ah yes, sorry about that - I didn't realise you had added extra test cases that did not involve the should-not-typecheck function. It seems that the behaviour of GHC's deferred type errors has changed between 7.10.3 and 8.0.1:

$ stack ghci --resolver lts-6
Configuring GHCi with the following packages: should-not-typecheck
GHCi, version 7.10.3: http://www.haskell.org/ghc/  :? for help
λ> :set -fdefer-type-errors
λ> let y = ("hello", "world" / True)

<interactive>:4:27: Warning:
    No instance for (Fractional [Char]) arising from a use of ‘/’
    In the expression: "world" / True
    In the expression: ("hello", "world" / True)
    In an equation for ‘y’: y = ("hello", "world" / True)

<interactive>:4:29: Warning:
    Couldn't match expected type ‘[Char]’ with actual type ‘Bool’
    In the second argument of ‘(/)’, namely ‘True’
    In the expression: "world" / True
λ> fst y
"hello"

vs

$ stack ghci
Configuring GHCi with the following packages: should-not-typecheck
GHCi, version 8.0.1: http://www.haskell.org/ghc/  :? for help
λ> :set -fdefer-type-errors
λ> let y = ("hello", "world" / True)

<interactive>:2:29: warning: [-Wdeferred-type-errors]
    • Couldn't match expected type ‘[Char]’ with actual type ‘Bool’
    • In the second argument of ‘(/)’, namely ‘True’
      In the expression: "world" / True
      In the expression: ("hello", "world" / True)
λ> fst y
"*** Exception: <interactive>:2:29: error:
    • Couldn't match expected type ‘[Char]’ with actual type ‘Bool’
    • In the second argument of ‘(/)’, namely ‘True’
      In the expression: "world" / True
      In the expression: ("hello", "world" / True)
(deferred type error)

This is less than ideal; it seems GHC now puts the type error at a higher level binding than before so will error out more aggressively. This is probably a GHC bug - at least I would expect deferred type errors to be a lazy as possible. Unfortunately, as a lowly library author I don't think I can fix this - we're going to need to make a GHC bug report and hope someone fixes it.

Anyhow, while I can see this is a problem for your two failing tests as they're trying to demonstrate how deferred type errors work, I would question whether this is a bug for this particular library - any tests with should-not-typecheck will be using the shouldNotTypecheck function which actually wants to have the deferred type errors exposed as soon as possible once called (that's why we have the NFData constraint). The reason your two tests are failing are because they're not using the shouldNotTypecheck function and simply testing the behaviour of GHC. In fact, I wonder if this change in behaviour might be beneficial for this library - we might be able to remove the NFData constraint altogether.

[CRogers]

In fact, after just testing it, it seems that you do no longer need the NFData constraint with this new GHC behaviour!