Opened 5 years ago

Closed 3 years ago

#2846 closed bug (fixed)

Impredicativity bug: GHC crash by type signature

Reported by: mm_freak Owned by: simonpj
Priority: low Milestone: 7.0.1
Component: Compiler Version: 6.10.1
Keywords: crash, type Cc: michal.terepeta@…
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Difficulty: Unknown
Test Case: T2846, T2846b Blocked By:
Blocking: Related Tickets:

Description

Quick and dirty, this is the bug:

Prelude> [1,2,3] :: [Num a => a]
ghc: panic! (the 'impossible' happened)
  (GHC version 6.10.1 for i386-unknown-linux):
        TcTyFuns.flattenType: unexpected PredType

I'm running Gentoo Linux. I can reproduce this bug in the interpreter as well as in the compiler. It seems like it happens only with -fglasgow-exts, and only if you use show on that specific list. It doesn't happen, if you only use the head or the tail of the list. There is also no problem with appending something using (++) or consing through (:).

This is an amd64 architecture, but I'm using a 32 bits system, so this should be irrelevant.

Change History (9)

comment:1 Changed 5 years ago by igloo

  • Architecture changed from x86_64 (amd64) to Unknown/Multiple
  • Difficulty set to Unknown
  • Milestone set to 6.10.2
  • Operating System changed from Linux to Unknown/Multiple

Thanks for the report.

comment:2 Changed 5 years ago by simonpj

  • Milestone changed from 6.10.2 to 6.12 branch
  • Summary changed from GHC crash by type signature to Impredicativity bug: GHC crash by type signature

What's happening here is that -fglasgow-exts implies -XImpredicativeTypes and -XFlexibleContexts. Then we get a constraint (Show [Num a => a]), which should never happen. The impredicative machinery should not allow polymorphism in class constraints, but that check isn't implemented.

The impredicative stuff needs a proper overhaul (Dimitrios is working on it) so I do not propose to tweak it now. But this should be fixed in due course.

Meanwhile, I propose to stop -fglasgow-exts from implying -XImpredicativeTypes. I don't want to encourage use of impredicativity until it's working properly.

Simon

comment:3 Changed 5 years ago by nccb

Just to add another example, I believe this is the same bug:

forFD :: (forall a. Floating a => a -> IO ()) -> [forall a. Floating a => a] -> IO ()
forFD f xs = mapM_ f xsf >> mapM_ f xsd
  where
    xsf :: [Float]
    xsf = [x | x <- xs]
    xsd :: [Double]
    xsd = [x | x <- xs]

forIFD :: (forall a. Num a => a -> IO ()) -> [forall a. Num a => a] -> IO ()
forIFD f xs = mapM_ f xsi >> forFD f xs'
  where
    xsi :: [Int]
    xsi = [x | x <- xs]
    xs' :: [Floating a => a]
    xs' = [x | x <- xs]

Then "ghc -XRank2Types -XImpredicativeTypes -XFlexibleContexts tmp.hs" gives:

ghc: panic! (the 'impossible' happened)
  (GHC version 6.10.1 for x86_64-unknown-linux):
        TcTyFuns.flattenType: unexpected PredType

Adding "forall a." to the type of the list xs' fixes the bug (even if the code cannot type-check in its current form) but I thought I'd post it here in case it helps.

comment:4 Changed 5 years ago by simonpj

Thanks. FWIW, we did not remove -XImpredicativeTypes from -fglasgow-exts in 6.10.2, because that's an interface change. But it's gone from -fglasgow-exts in the HEAD.

Cleaning the impredicative stables is still in the pipeline for 6.12.

Simon

comment:5 Changed 4 years ago by igloo

  • Milestone changed from 6.12 branch to 6.12.3

comment:6 Changed 4 years ago by igloo

  • Milestone changed from 6.12.3 to 6.14.1
  • Priority changed from normal to low

comment:7 Changed 3 years ago by michalt

  • Cc michal.terepeta@… added
  • Type of failure set to None/Unknown

Seems to be fixed:

Prelude> [1,2,3] :: [Num a => a]

<interactive>:1:1:
    No instance for (Show (Num a => a))
      arising from a use of `print'
    Possible fix: add an instance declaration for (Show (Num a => a))
    In a stmt of an interactive GHCi command: print it

This is from ghc 7.1.20101028, but I'm getting pretty much the same error with 6.12.3.

comment:8 Changed 3 years ago by igloo

  • Owner set to simonpj
  • Test Case set to T2846, T2846b

Thanks, I've added a test.

Simon, is the current behaviour OK - i.e. can we close this ticket?

comment:9 Changed 3 years ago by simonpj

  • Resolution set to fixed
  • Status changed from new to closed

Yes, that's fine. The error message Michal gives is with -XImpredicativeTypes. Without we get

T2846.hs:4:5:
    Illegal polymorphic or qualified type: Num a => a
    Perhaps you intended to use -XImpredicativeTypes
    In an expression type signature: [Num a => a]
    In the expression: [1, 2, 3] :: [Num a => a]
    In an equation for `x': x = [1, 2, 3] :: [Num a => a]
Note: See TracTickets for help on using tickets.