Skip to content

Reject dodgy scoping in associated family instance RHSes

Ryan Scott requested to merge wip/T18021 into master

Commit e63518f5 tried to push all of the logic of detecting out-of-scope type variables on the RHSes of associated type family instances to GHC.Tc.Validity by deleting a similar check in the renamer. Unfortunately, this commit went a little too far, as there are some corner cases that GHC.Tc.Validity doesn't detect. Consider this example:

class C a where
  data D a

instance forall a. C Int where
  data instance D Int = MkD a

If this program isn't rejected by the time it reaches the typechecker, then GHC will believe the a in MkD a is existentially quantified and accept it. This is almost surely not what the user wants! The simplest way to reject programs like this is to restore the old validity check in the renamer (search for improperly_scoped in rnFamEqn).

Note that this is technically a breaking change, since the program in the polykinds/T9574 test case (which previously compiled) will now be rejected:

instance Funct ('KProxy :: KProxy o) where
    type Codomain 'KProxy = NatTr (Proxy :: o -> *)

This is because the o on the RHS will now be rejected for being out of scope. Luckily, this is simple to repair:

instance Funct ('KProxy :: KProxy o) where
    type Codomain ('KProxy @o) = NatTr (Proxy :: o -> *)

All of the discussion is now a part of the revamped Note [Renaming associated types] in GHC.Rename.Module.

A different design would be to make associated type family instances have completely separate scoping from the parent instance declaration, much like how associated type family default declarations work today. See the discussion beginning at #18021 (closed) (comment 265729) for more on this point. This, however, would break even more programs that are accepted today and likely warrants a GHC proposal before going forward. In the meantime, this patch fixes the issue described in #18021 (closed) in the least invasive way possible. There are programs that are accepted today that will no longer be accepted after this patch, but they are arguably pathological programs, and they are simple to repair.

Fixes #18021 (closed).

Merge request reports