Typed hole inside typed Template Haskell bracket causes panic

When I say:

m :: a -> a
m x = $$([||_||])

I get:

T10946.hs:47:13:ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.1 for x86_64-unknown-linux):
        No skolem info: a_apJ[sk]

This happens both with GHC 7.10.1 and latest HEAD (e2b579e8).

Trac metadata

Trac field	Value
Version	7.10.1
Type	Bug
TypeOfFailure	OtherFailure
Priority	high
Resolution	Unresolved
Component	Template Haskell
Test case
Differential revisions
BlockedBy
Related
Blocking
CC	goldfire
Operating system
Architecture

mentioned in issue #10045 (closed)

mentioned in issue #10267 (closed)

changed milestone to %8.0.1

changed weight to 7

added Tbug TemplateHaskell Trac import labels

This error is raised in TcErrors.getSkolemInfo called from TcErrors.mkHoleError. Quick look at the code tells me that "implication constraints" are expected to be non-empty but they are. Are implication constraints things that come in the contexts, ie. everything before a =>? Why are they expected to be non-empty?

mentioned in commit f64f7c36

Trac metadata

Trac field	Value
Test case	- → th/T10946

mentioned in commit 75492e74

mentioned in issue #11347 (closed)

changed milestone to %8.2.1

This still fails and won't be fixed for 8.0.1.

mentioned in commit c6ac1e5f

changed milestone to %8.4.1

It looks like this won't happen for 8.2 either.

The problem seems to be that the quoted expression [|| _x ||] will introduce a hole constraint of the form _x :: a when spliced, but that the error will be reported outside of the implication introduced by the signature. When checking the following program:

m :: a
m  = _x

simplifyTop will report that it's found an unsolved wanted constraint of the form forall (a :: *). () => _x :: a. However, when checking the original program, simplifyTop is called from a different path (tcTopSpliceExpr), and reports the wanted constraint as being of the form _x :: a. As it lacks the context of the binding for a, it falls through to the base case of getSkolemInfo, which causes the panic.

At this point, I'm not sure what the right path forward is. Should tcTopSpliceExpr be using simplifyTop, or is there just some additional context needed to be setup before that call?

So in f64f7c36, we added a test case for this that was marked as expect_broken. However, that program now loops infinitely on GHC HEAD!

$ inplace/bin/ghc-stage2 --interactive
GHCi, version 8.5.20180305: http://www.haskell.org/ghc/  :? for help
Loaded GHCi configuration from /home/rgscott/.ghci
λ> :set -XTemplateHaskell
λ> m :: a -> a; m x = $$([||_||]) -- Loops infinitely
^CInterrupted.

Should we disable the test case entirely in the meantime?

A correction to ticket:10946#comment:150039—it doesn't loop infinitely, but it does take a full five minutes to complete that test case on my machine. Still, that's quite severe—we should find out what caused this to regress.

It looks like much of the slowdown was introduced in commit cbdea959 (Sort valid substitutions for typed holes by "relevance").

Tritlo, do you have any idea what might be happening here?

RyanGlScott: It seems like what's happening is that since the variable has no constraints on it at all, then it's matching everything in scope (including everything in scope in TemplateHaskell), and then doing the subsumption graph sorting on that, which takes a very long time. I'll give it some thought, but it seems like the right way to go would be to not try to find valid substitutions for this too general case.