Opened 2 years ago

Last modified 9 months ago

#13981 new bug

Family instance consistency checks happens too early when hs-boot defined type occurs on LHS

Reported by: ezyang Owned by:
Priority: normal Milestone: 8.10.1
Component: Compiler (Type checker) Version: 8.2.1-rc2
Keywords: hs-boot Cc: inaki
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: None/Unknown Test Case:
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by bgamari)

This is a follow up ticket for #13803, since I wanted to fix the immediate bug in #13803 without having to deal with the more complicated case here:

-- F.hs
{-# LANGUAGE TypeFamilies #-}
module F where
type family F a :: *

-- A.hs-boot
module A where
data T

-- B.hs
{-# LANGUAGE TypeFamilies #-}
module B where
import {-# SOURCE #-} A
import F
type instance F T = Int

-- C.hs
{-# LANGUAGE TypeFamilies #-}
module C where
import {-# SOURCE #-} A
import F
type instance F T = Bool

-- A.hs
module A where
import B
import C

data T = T

From what I wrote: right now, we decide to defer a type family consistency check if the family was recursively defined. If the RHS refers to a recursively defined type, there's no problem: we don't need to look at it for consistency checking. But if the LHS is recursively defined, as is in this example, we DO need to defer the check.

But it's a bit irritating to figure out whether or not there's actually a reference to a recursively defined type in the LHS, since this involves traversing the LHS types, and if we're not careful we'll end up pulling in the TyThing anyway. There are two other possibilities: (1) always defer checking instances which are defined inside the recursive look (by looking at the Name of the axiom), or (2) annotating IfaceAxiom with the set of boot types its LHS refers to, for easy checking. Not entirely sure what the best action is.

Change History (17)

comment:1 Changed 2 years ago by simonpj

right now, we decide to defer a type family consistency check if the family was recursively defined.

I don't like the sound of that. Strange deferring under special circumstances. Can we figure out a more uniform approach?

I've lost context here. In your example, modules B and C seem to have no overlap problem, but A does. Can you set out the problem you are trying to solve, ab-initio?

comment:2 Changed 2 years ago by ezyang

Yeah. The details are in Note [Don't check hs-boot type family instances too early], but reproduced below:

  • So, the origin of a panic "tcIfaceGlobal (local): not found" is when force the TyThing of a locally defined type prior to having actually typechecked that type. Ordinarily this can't happen (since you can't even get your hands on the TyThing before you've typechecked the type), but when you have an hs-boot file, a placeholder thunk for the TyThing is put into the context, and the onus is on you to avoid forcing this thunk until it is ready.
  • Type family consistency checking happens prior to any typechecking, and (as first discovered in #11062) it can cause a TyThing of an hs-boot defined type family to be forced too early. Originally, I suggested that we simply do the consistency check after all typechecking was done. But this has its own problem: if we do the consistency check too late, we may end up typechecking Haskell code under inconsistent/overlapping sets of axioms, which could lead to very strange errors.
  • Thus, we have to defer some of the consistency checks. We first do all of the consistency checks that could not possibly force a TyThing immediately, and then as we finish kind-checking a type family, we then go ahead and do all of the deferred consistency checks involving that family.
  • What I didn't realize when I originally wrote this patch is that the early forcing isn't limited just to a type family: types which occur in the LHS of overlapping instances (T above) also have this problem. So some new solution needs to be found.

comment:3 Changed 2 years ago by simonpj

Description: modified (diff)

comment:4 Changed 2 years ago by Ben Gamari <ben@…>

In fdb6a5b/ghc:

Make IfaceAxiom typechecking lazier.

Fixes #13803, but adds a note about a yet to be fixed #13981.

Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>

Test Plan: validate

Reviewers: bgamari, austin

Reviewed By: bgamari

Subscribers: simonpj, rwbarton, thomie

GHC Trac Issues: #13803

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

comment:5 Changed 2 years ago by bgamari

Description: modified (diff)
Milestone: 8.2.1
Resolution: fixed
Status: newclosed

comment:6 Changed 2 years ago by inaki

Cc: inaki added

comment:7 Changed 2 years ago by inaki

I think that this issue got perhaps closed by mistake?

The commit mentions explicitly that this issue is not fixed yet, and ghc A.hs does indeed still give rise to a panic.

comment:8 Changed 2 years ago by bgamari

Milestone: 8.2.18.4.1
Resolution: fixed
Status: closednew

Indeed it did. Thanks for bringing this to my attention.

comment:9 Changed 2 years ago by inaki

I am starting to receive bug reports for the packages I maintain (these are the bindings for gtk and other libraries autogenerated by http://github.com/haskell-gi/haskell-gi) from people running into this issue. Is there some workaround I could apply to avoid the panic?

I would be happy to help fixing the bug properly, of course, but I have not clue where to start, and that would in any case not help for the crashes with the already released 8.2.1.

comment:10 Changed 2 years ago by ezyang

comment:11 Changed 2 years ago by ezyang

I can't look into the problem right now, but if there is another minimization that demonstrates the problem, that would be very helpful. Does haskell-gi define type families? If it doesn't, this particular issue is unlikely to be the problem.

comment:12 in reply to:  11 Changed 2 years ago by inaki

Replying to ezyang:

I can't look into the problem right now, but if there is another minimization that demonstrates the problem, that would be very helpful.

OK, I'll give it a try again, now that I have a better idea of what's going on.

Does haskell-gi define type families? If it doesn't, this particular issue is unlikely to be the problem.

Yes, it uses them extensively. In fact, if I remove the type-family related code the issue disappears.

comment:13 in reply to:  11 Changed 2 years ago by inaki

Replying to ezyang:

I can't look into the problem right now, but if there is another minimization that demonstrates the problem, that would be very helpful.

I just spent a good while trying to do this, but got badly misled by what I think is a different issue: #14075. I think that it is different because that one disappears when I use -j1, while the panic when compiling gi-gio remains. I will retry to re-minimize without using parallel make (hopefully side-stepping #14075 in this way) when I get a chance.

comment:14 Changed 2 years ago by inaki

OK, I managed to minimize the problem, it seems to be indeed related to type families. I have filed a separate issue, but perhaps it is the same thing as in this one: #14080.

comment:15 Changed 20 months ago by bgamari

Milestone: 8.4.18.6.1

This ticket won't be resolved in 8.4; remilestoning for 8.6. Do holler if you are affected by this or would otherwise like to work on it.

comment:16 Changed 15 months ago by bgamari

Milestone: 8.6.18.8.1

These won't be addressed by GHC 8.6.

comment:17 Changed 9 months ago by osa1

Milestone: 8.8.18.10.1

Bumping milestones of low-priority tickets.

Note: See TracTickets for help on using tickets.