Opened 3 years ago

Closed 3 years ago

Last modified 23 months ago

#10045 closed bug (fixed)

type holes related ghc panic

Reported by: pacak Owned by: thoughtpolice
Priority: normal Milestone: 8.0.1
Component: Compiler Version: 7.10.1-rc2
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s): Phab:D646
Wiki Page:

Description

sample.hs:9:13:
    Couldn't match expected type ‘t’ with actual type ‘()’
      ‘t’ is untouchable
        inside the constraints ()
        bound by the inferred type of foo :: Meta -> t1
        at sample.hs:(6,1)-(9,17)ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.0.0 for x86_64-unknown-linux):
        No skolem info: t_avJ[sk]

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug


sample.hs:
module Blah where

newtype Meta = Meta ()

foo (Meta ws1) =
    let copy :: _
        copy w from = copy w 1
    in copy ws1 1

Change History (15)

comment:1 Changed 3 years ago by thomasw

Differential Rev(s): Phab:D646
Owner: set to thomasw

comment:2 Changed 3 years ago by Austin Seipp <austin@…>

In e9d72cefeda243d5962d0615fe7ad22ff615d134/ghc:

Fix #10045

Summary:
SPJ's solution is to only bring the `TcId` (which includes the type) of a
binder into scope when it had a non-partial type signature.

Take care of this by only storing the `TcId` in `TcSigInfo` of non-partial
type signatures, hence the change to `sig_poly_id :: Maybe TcId`. Only in case
of a `Just` will we bring the `TcId` in scope. We still need to know the name
of the binder, even when it has a partial type signature, so add a `sig_name
:: Name` field. The field `sig_partial :: Bool` is no longer necessary, so
reimplement `isPartialSig` in terms of `sig_poly_id`.

Note that the new test case fails, but not because of a panic, but because the
`Num a` constraint is missing. Adding an extra-constraints wildcard to
`copy`'s signature would fix it.

Test Plan: validate

Reviewers: simonpj, austin

Reviewed By: simonpj

Subscribers: thomie

Differential Revision: https://phabricator.haskell.org/D646

GHC Trac Issues: #10045

comment:3 Changed 3 years ago by darchon

I'm terribly sorry for, once again, bringing up tickets late in the release cycle... but can the above fix be included in ghc 7.10? I'm getting:

~/devel/test$ ghci Blah.hs 
GHCi, version 7.10.0.20150323: http://www.haskell.org/ghc/  :? for help
[1 of 1] Compiling Blah             ( Blah.hs, interpreted )

Blah.hs:7:17:
    Found hole ‘_’ with type: t2 -> a1 -> t3
    Where: ‘t2’ is a rigid type variable bound by
                the inferred type of copy :: Num a1 => t2 -> a1 -> t3
                at Blah.hs:8:9
           ‘t3’ is a rigid type variable bound by
                the inferred type of copy :: Num a1 => t2 -> a1 -> t3
                at Blah.hs:8:9
           ‘a1’ is a rigid type variable bound by
                the inferred type of copy :: Num a1 => t2 -> a1 -> t3
                at Blah.hs:8:9
    To use the inferred type, enable PartialTypeSignatures
    Relevant bindings include
      ws1 :: () (bound at Blah.hs:6:11)
      foo :: Meta -> t3 (bound at Blah.hs:6:1)
    In the type signature for ‘copy’: _
    In the expression:
      let
        copy :: _
        copy w from = copy w 1
      in copy ws1 1
    In an equation for ‘foo’:
        foo (Meta ws1)
          = let
              copy :: _
              copy w from = copy w 1
            in copy ws1 1

Blah.hs:8:9:
    No instance for (Num a)
    When checking that ‘copy’ has the specified type
      copy :: forall t t1 a. t -> a -> t1
    Probable cause: the inferred type is ambiguous
    In the expression:
      let
        copy :: _
        copy w from = copy w 1
      in copy ws1 1
    In an equation for ‘foo’:
        foo (Meta ws1)
          = let
              copy :: _
              copy w from = copy w 1
            in copy ws1 1

Blah.hs:9:13:
    Couldn't match expected type ‘t’ with actual type ‘()’
      ‘t’ is untouchable
        inside the constraints ()
        bound by the inferred type of foo :: Meta -> t1
        at Blah.hs:(6,1)-(9,17)ghc: panic! (the 'impossible' happened)
  (GHC version 7.10.0.20150323 for x86_64-apple-darwin):
	No skolem info: t_avM[sk]

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Also, this is not mission critical for me! So if it's postponed to a later release then it's no problem.

comment:4 Changed 3 years ago by hvr

Milestone: 7.10.1

comment:5 Changed 3 years ago by hvr

Status: newmerge

comment:6 Changed 3 years ago by thoughtpolice

Milestone: 7.10.17.10.2

Moving to GHC 7.10.2.

comment:7 Changed 3 years ago by thoughtpolice

Resolution: fixed
Status: mergeclosed

Sorry, the patch in question is a bit tricky to merge as it has some dependencies. We may be able to revisit this one for 7.10.2, so I've pushed it off to said milestone.

comment:8 Changed 3 years ago by thoughtpolice

Owner: thomasw deleted
Resolution: fixed
Status: closednew

comment:9 Changed 3 years ago by simonpj

Owner: set to thoughtpolice

comment:10 Changed 3 years ago by simonpj

Status: newmerge

I'll put this into the 7.10.2 merge queue so that Austin looks at it again

comment:11 Changed 3 years ago by thoughtpolice

Milestone: 7.10.27.12.1
Resolution: fixed
Status: mergeclosed

I looked at it again, and I'm still inclined to leave it out. :) It would be possible to remove the bits from the redundant superclass warning patch that touch it, but it looks like there have been some other various changes resulting in quite a few hunks that don't match up.

So, unless someone Really Really needs it (or would like to backport the patch themselves!), I'd prefer to keep this one pointed to 7.12.1.

comment:12 Changed 2 years ago by thoughtpolice

Milestone: 7.12.18.0.1

Milestone renamed

comment:13 Changed 2 years ago by Simon Peyton Jones <simonpj@…>

In f86fb5e5/ghc:

Add regression tests for #10045, #10999

comment:14 Changed 2 years ago by jstolarek

Can #10946 be in any way related to this?

comment:15 Changed 23 months ago by nomeata

Too bad this did not make it into 7.10.3. The bug happens when trying out the code that explains how to derive unsafeCoerce from GND+TypeFamilies if we had not roles.

(This comment has little nutritional content.)

Note: See TracTickets for help on using tickets.