Kind variable scoping problem in Iface file when using Template Haskell

[goldfire]

Consider the following modules:

module PolykindTH where

import Language.Haskell.TH

makeSList :: Q [Dec]
makeSList = do
  a <- newName "a"
  k <- newName "k"
  return [TySynD (mkName "SList") [KindedTV a (AppT ListT (VarT k))]
                 (AppT (ConT (mkName "Sing")) (VarT a))]
-- makes "type SList (a :: [k]) = Sing a"

{-# LANGUAGE PolyKinds, TypeFamilies, DataKinds, TemplateHaskell #-}

module Polykind where

import PolykindTH

data family Sing (a :: k)

$( makeSList )

When these modules are compiled, the resultant Iface file fails to load when code attempts to use the modules. To check this, I packaged this up with a cabal file, registered the package with my GHC (7.5.20120620), and then attempted to compile the following:

import Polykind

foo :: SList a -> Bool
foo = undefined

Here is the error:

Declaration for SList:
  Iface type variable out of scope:  k
Cannot continue after interface file error

I have attached a tarball of my cabal package for ease of testing.

[goldfire]

sample cabal package exhibiting error

[simonpj@…]

commit 3fe3ef509627cb8c9aa7751beb44d1b4408f8b22

Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Tue Jul 10 16:02:03 2012 +0100

    More changes to kind inference for type and class declarations
    
    These should fix #7024 and #7022, among others.
    
    The main difficulty was that we were getting occ-name clashes
    between kind and type variables in TyCons, when spat into an
    interface file. The new scheme is to tidy TyCons during the
    conversoin into IfaceSyn, rather than trying to generate them
    pre-tidied, which was the already-unsatisfactory previous plan.
    
    There is the usual wave of refactorig as well.

 compiler/iface/MkIface.lhs          |  129 +++++++++++++++++++++-----------
 compiler/typecheck/TcHsType.lhs     |  143 ++++++++++++++++++++---------------
 compiler/typecheck/TcRnDriver.lhs   |    8 +-
 compiler/typecheck/TcRnTypes.lhs    |   40 +++++++---
 compiler/typecheck/TcRules.lhs      |    3 +-
 compiler/typecheck/TcTyClsDecls.lhs |  110 +++++++++++++-------------
 compiler/types/Kind.lhs             |    9 ++-
 7 files changed, 267 insertions(+), 175 deletions(-)

[simonpj]

I've added a test.

Simon

[goldfire]

This bug still fails for me (on a Mac, using GHC 7.5.20120720). But, rather curiously, the error message has changed:

Declaration for SList
Type syonym Polykind.SList:
  Iface type variable out of scope:  a
Cannot continue after interface file error

Now, a is out of scope, instead of k previously. (Also, there is evidently a typo in the word 'syonym' in the error.)

I have a more elaborate test case (in the style of #7024) if you need it.

[simonpj]

Well that's odd. The code in the Description of this ticket works fine for me. It's even in the regression suite. Are you saying that the regression test fails for you (polykinds/T7022)? Can you say precisely what happens, including exactly the code you are compiling?

Simon

[goldfire]

I'm performing the setup and compiling the code exactly as specified in the initial bug report: I download the polykind.tar.gz file attached, unpack it, add it to my in-place GHC, and then run the code pasted above (

import Polykind

foo :: SList a -> Bool
foo = undefined

) in a fresh file, getting the error reported a few days ago. The procedure for adding the package to GHC is (in the unpacked directory)

ghc75 --make Setup.hs
./Setup configure --with-ghc=/Users/rae/Documents/ghc/inplace/bin/ghc-stage2 --global
./Setup build
./Setup register --inplace

where ghc75 is a symlink to the in-place ghc.

I looked at polykinds/T7022, and it looks to me that it doesn't test the error I initially reported. The test compiles the module code and checks that process for errors. That has always worked fine. The problem occurs when compiling the foo function against the compiled module declaring SList. I could find no procedure for testing code against the compiled module in the T7022 test. In any case, the T7022 test passes for me.

I hope this helps narrow the problem!

[simonpj]

Aha. I don't have time to validate, but I bet this fixes it:

diff --git a/compiler/iface/MkIface.lhs b/compiler/iface/MkIface.lhs
index ce07b37..18dd8f4 100644
--- a/compiler/iface/MkIface.lhs
+++ b/compiler/iface/MkIface.lhs
@@ -1498,8 +1498,8 @@ tyConToIfaceDecl env tycon
 
     (syn_rhs, syn_ki) 
        = case synTyConRhs tycon of
-            SynFamilyTyCon  -> (Nothing,               tidyToIfaceType env1 (synTyConResKind tycon))
-            SynonymTyCon ty -> (Just (toIfaceType ty), tidyToIfaceType env1 (typeKind ty))
+            SynFamilyTyCon  -> (Nothing,                        tidyToIfaceType env1 (synTyConResKind tycon))
+            SynonymTyCon ty -> (Just (tidyToIfaceType env1 ty), tidyToIfaceType env1 (typeKind ty))
 
     ifaceConDecls (NewTyCon { data_con = con })     = IfNewTyCon  (ifaceConDecl con)

Can you test, validate, and commit if so? It's just a typo in my previous fix.

[marlowsd@…]

commit 15e4f93b661fe83cff96c8c295e7ea8985aa08aa

Author: Simon Marlow <marlowsd@gmail.com>
Date:   Thu Aug 2 11:47:51 2012 +0100

    applying simonpj's fix from #7022 (with 80-col reformatting)

 compiler/iface/MkIface.lhs |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

[simonmar]

does this need a new regression test?

[simonmar]

Also note that the fix caused a failure in rnfail055:

--- ./rename/should_fail/rnfail055.stderr	2012-07-10 16:59:23.000000000 +0100
+++ ./rename/should_fail/rnfail055.comp.stderr	2012-08-02 13:13:42.277992885 +0100
@@ -17,8 +17,8 @@
 
 RnFail055.hs-boot:8:6:
     Type constructor `S2' has conflicting definitions in the module and its hs-boot file
-    Main module: type S2 a b = forall a. (a, b)
-    Boot file:   type S2 a b = forall b. (a, b)
+    Main module: type S2 a b = forall a1. (a1, b)
+    Boot file:   type S2 a b = forall b1. (a, b1)

I didn't think the failure looked serious so I committed the new output, but maybe someone wants to look into it further.

[simonpj]

The rnfail055 error is fine. I've updated the test to test for Richard's error.

[goldfire]

Is it possible to merge this bugfix into ghc7.6? When I tested for this bug on the release candidate, the bug was there. This bug stops my singletons library from working smoothly. Thanks!

[simonpj]

Yes, pls merge to 7.6

[pcapriotti]

Merged as 309eee74e0c7658c8ca3652106fdc1710f30e4d3.