Opened 7 months ago

Closed 7 months ago

#13394 closed bug (fixed)

PatternSynonyms/OverloadedStrings regression in GHC HEAD

Reported by: RyanGlScott Owned by:
Priority: highest Milestone: 8.2.1
Component: Compiler Version: 8.1
Keywords: PatternSynonyms Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash or panic Test Case: polykinds/T13394, T13394a
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description

purescript-0.10.7 fails to build with GHC HEAD at the moment due to an apparent regression in the way pattern synonyms and overloaded strings interact. Here is a simplified example:

{-# LANGUAGE OverloadedStrings #-}
{-# LANGUAGE PatternSynonyms #-}
module Bug where

import Data.ByteString

newtype ProperName =
  ProperName { runProperName :: ByteString
               -- purescript actually uses the Text type, but this works
               -- just as well for the purposes of illustrating the bug
             }
newtype ModuleName = ModuleName [ProperName]

pattern TypeDataSymbol :: ModuleName
pattern TypeDataSymbol = ModuleName [ProperName "Type",ProperName "Data", ProperName "Symbol"]

Compiling this with GHC 7.10.3 or 8.0.2 works without issue. In GHC HEAD, if you compile this with optimization enabled, it'll trigger a GHC panic:

$ ~/Software/ghc5/inplace/bin/ghc-stage2 -O1 -fforce-recomp Bug.hs                                                                     
[1 of 1] Compiling Bug              ( Bug.hs, Bug.o )                                     
ghc-stage2: panic! (the 'impossible' happened)                                            
  (GHC version 8.1.20170303 for x86_64-unknown-linux):                                    
        isUnliftedType                                                                    
  r_a28T :: TYPE rep_a28S                                                                 
  Call stack:                                                                             
      CallStack (from HasCallStack):                                                      
        prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable                                                                                    
        callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable    
        pprPanic, called at compiler/types/Type.hs:1961:10 in ghc:Type

The presence of optimization is crucial for reproducing this bug, as compiling it with -O0 does not trigger the panic.

Change History (6)

comment:1 Changed 7 months ago by simonpj

Aha. Thanks. Easy fix validating now.

comment:2 Changed 7 months ago by Simon Peyton Jones <simonpj@…>

In 8e05370/ghc:

Join points can be levity-polymorphic

It's ok to have a levity-polymorphic join point, thus
   let j :: r :: TYPE l = blah
   in ...

Usually we don't allow levity-polymorphic binders, but join points
are different because they are not first class.  I updated the
invariants in CoreSyn.

This commit fixes Trac #13394.

comment:3 Changed 7 months ago by simonpj

Resolution: fixed
Status: newclosed
Test Case: polykinds/T13394

comment:4 Changed 7 months ago by RyanGlScott

Resolution: fixed
Status: closednew

Thanks, Simon. But you didn't include the original program as the test case! Rather, you included a slightly tweaked program that doesn't have as many list elements in TypeDataSymbol. This is crucial, as the original program still fails with a GHC panic even after 8e053700f9357c1b9030c406130062795ae5015c:

$ ~/Software/ghc2/inplace/bin/ghc-stage2 -O1 -fforce-recomp Bug.hs
[1 of 1] Compiling Bug              ( Bug.hs, Bug.o )
ghc-stage2: panic! (the 'impossible' happened)
  (GHC version 8.1.20170307 for x86_64-unknown-linux):
        runtimeRepPrimRep
  typePrimRep (r_a28P :: TYPE rep_a28O)
  rep_a28O
  Call stack:
      CallStack (from HasCallStack):
        prettyCurrentCallStack, called at compiler/utils/Outputable.hs:1191:58 in ghc:Outputable
        callStackDoc, called at compiler/utils/Outputable.hs:1195:37 in ghc:Outputable
        pprPanic, called at compiler/simplStg/RepType.hs:360:5 in ghc:RepType

comment:5 Changed 7 months ago by Simon Peyton Jones <simonpj@…>

In bc0f3ab/ghc:

Deal with JoinIds before void types

Trac #13394, comment:4 showed up another place where we were testing
for the representation of of a type; and it turned out to be a JoinId
which can be rep-polymorphic.

Just putting the test in the right places solves this easily.

comment:6 Changed 7 months ago by simonpj

Resolution: fixed
Status: newclosed
Test Case: polykinds/T13394polykinds/T13394, T13394a

OK, now it should be fixed. There was a second bug!

Note: See TracTickets for help on using tickets.