Opened 2 years ago

Last modified 7 months ago

#10946 new bug

Typed hole inside typed Template Haskell bracket causes panic

Reported by: jstolarek Owned by:
Priority: high Milestone: 8.4.1
Component: Template Haskell Version: 7.10.1
Keywords: Cc: goldfire
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash Test Case: th/T10946
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

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 (e2b579e8d77357e8b36f57d15daead101586ac8e).

Change History (8)

comment:1 Changed 2 years ago by jstolarek

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?

comment:2 Changed 2 years ago by Jan Stolarek <jan.stolarek@…>

In f64f7c3/ghc:

Tests for #10945 and #10946

comment:3 Changed 2 years ago by jstolarek

Test Case: th/T10946

comment:4 Changed 2 years ago by Jan Stolarek <jan.stolarek@…>

In 75492e7/ghc:

Add typed holes support in Template Haskell.

Fixes #10267. Typed holes in typed Template Haskell currently don't work.
See #10945 and #10946.

comment:5 Changed 19 months ago by bgamari

Milestone: 8.0.18.2.1

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

comment:6 Changed 13 months ago by Ben Gamari <ben@…>

In c6ac1e5/ghc:

users_guide: TH now partially supports typed holes

As requested in #10267. However we still lack support in typed splices.
See #10945 and #10946.

comment:7 Changed 9 months ago by bgamari

Milestone: 8.2.18.4.1

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

comment:8 Changed 7 months ago by elliottt

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?

Note: See TracTickets for help on using tickets.