#13487: GHC panic with deferred custom type errors -------------------------------------+------------------------------------- Reporter: DimaSamoz | Owner: (none) Type: bug | Status: new Priority: normal | Milestone: 8.4.1 Component: GHCi | Version: 8.0.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: Compile-time | Unknown/Multiple crash or panic | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by DimaSamoz): Adding {{{ #!haskell c = evaluate ('a' :-: 'b') }}} to the above example, then loading it and querying the value of `c` also triggers the panic. This wouldn't be surprising if GHCi called `evaluate` upon let bindings, but surely that's not the case? I encountered this error when trying to test my library using the `should- not-typecheck` package (https://hackage.haskell.org/package/should-not- typecheck), which provides a HSpec assertion `shouldNotTypecheck` that passes only if the argument doesn't compile (hence the need for deferred type errors). I eventually realised that the library doesn't work with custom compiler errors: the function performs a case split on the result of `try (evaluate $ force a)` (for the argument `a`), but terms with custom type errors never got into the `Left (TypeError msg)` case (where the assertion could pass), so the function thought that the argument compiles. This might not be directly related, but I thought I would mention it in case it is! -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13487#comment:3 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler