Opened 2 years ago

Closed 2 years ago

Last modified 13 months ago

#10945 closed bug (fixed)

Typed Template Haskell splices broken in HEAD (7.11)

Reported by: jstolarek Owned by: jstolarek
Priority: high Milestone: 8.0.1
Component: Template Haskell Version: 7.11
Keywords: Cc: goldfire, simonpj
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case: th/T10945
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D1344
Wiki Page:

Description

In the latest HEAD (e2b579e8d77357e8b36f57d15daead101586ac8e) when I say:

$$(return [
   SigD (mkName "m")
        (ForallT [PlainTV (mkName "a")]
                 []
                 (AppT (AppT ArrowT (VarT (mkName "a"))) (VarT (mkName "a"))))
 , FunD (mkName "m")
        [Clause [VarP (mkName "x")] (NormalB (VarE (mkName "x"))) []]
 ])

I get:

ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 7.11.20151007 for x86_64-unknown-linux):
        runRnSplice
  $$(return
       [SigD
          (mkName "m")
          (ForallT
             [PlainTV (mkName "a")]
             []
             (AppT (AppT ArrowT (VarT (mkName "a"))) (VarT (mkName "a")))),
        FunD
          (mkName "m")
          [Clause [VarP (mkName "x")] (NormalB (VarE (mkName "x"))) []]])

This code compiles correctly in GHC 7.10.1.

Change History (12)

comment:1 Changed 2 years ago by jstolarek

Cc: simonpj added

The sequence of calls that leads to this panic goes like this: TcRnDriver.tc_rn_src_decls -> RnSplice.rnTopSpliceDecls -> RnSplice.runRnSplice and in runRnSplice we hit HsTypedSplice alternative in the case that scrutinizes splice'. Looking at git blame I conjecture that this bug was introduced in f46360ed7139ff25741b381647b0a0b6d1000d84 (but would need to bisect to verify), which was a fix for #10047.

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/T10945

comment:4 Changed 2 years ago by goldfire

Obviously we shouldn't panic, but the code above looks utterly bogus, for two reasons:

  1. According to my understanding, typed splices only work for expressions -- no other contexts allowed.
  1. The contents of a typed splice (of type a) must be Q (TExp a).

So the fact that this has ever been accepted (and what does it do?!?) is a bug.

Last edited 2 years ago by goldfire (previous) (diff)

comment:5 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:6 Changed 2 years ago by jstolarek

Owner: set to jstolarek

comment:7 Changed 2 years ago by jstolarek

I initially thought that this bogus code - ie. top-level typed TH splice - should be rejected as a parse error. I spent some time trying to change the parser to reject the code but I couldn't find a good way of doing that. Then I realized that this code should parse: with TH enabled all top-level expressions should really be accepted, including a typed TH splice. After some more thought I believe that the right way of doing this would be to run the typed TH splice and then report a type error in the same way we report a type error here:

{-# LANGUAGE TemplateHaskell #-}

module T10945s where

import Language.Haskell.TH

True
T10945.hs:8:1:
    Couldn't match type ‘Bool’ with ‘Q [Dec]’
    Expected type: DecsQ
      Actual type: Bool
    In the expression: True

Before investing more time into this I'd like to hear thoughts from other devs.

comment:8 Changed 2 years ago by jstolarek

Oh, I have a nearly-one-line fix. Will post patch later for review.

comment:9 Changed 2 years ago by jstolarek

Differential Rev(s): Phab:D1344

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

In 1750ebc2/ghc:

Reject top-level typed TH splices. Fixes #10945

When TemplateHaskell language extension is enabled it is valid to have
top-level expressions.  Each such expression is treated as a contents
of a splice.  The problem arises with typed splices.  They are not valid
at the top level and therefore we should interpret them not as a splice
but as a top-level expression (aka. implicit splice).  So saying:

$$foo

is equivalent of:

$( $$foo )

This patch makes sure that this is indeed the case.  Until now we
incorrectly treated typed splices as explicit splices.

comment:11 Changed 2 years ago by thomie

Resolution: fixed
Status: newclosed

The test is passing.

comment:12 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.
Note: See TracTickets for help on using tickets.