Iface type variable out of scope

I'm sorry for spamming code and not providing a distilled example, but honestly I have no idea how to even begin pinpointing this.

I'm writing a library and hosting it on Github: https://github.com/marcinmrotek/pipes-key-value-csv which compiles fine, but when I try to compile the test suite, GHC crashes with this error message:

/home/marcin/haskell/pipes-key-value-csv/.stack-work/dist/x86_64-linux/Cabal-1.22.4.0/build/Pipes/KeyValueCsv/Internal/KeyValue.hi
Declaration for $fFromKeyValuesf:3:
  Iface type variable out of scope:  k
Cannot continue after interface file error

when I uncomment the

. KV.foldHeader

line in https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/test/Test/KeyValue.hs

The thing is, this function does not even use the "FromKeyValues" type class mentioned - https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/src/Pipes/KeyValueCsv/Internal/KeyValue.hs

KV.parseLine, which does, compiles fine (the test suite runs and fails with "Prelude: undefined". They're both defined here: https://github.com/marcinmrotek/pipes-key-value-csv/blob/master/src/Pipes/KeyValueCsv/KeyValue.hs

I've tried "stack clean", reinstalling both GHC and stack, installing my package globally with cabal-install (although I had to fix the validation-0.5.1 package by removing the Safe pragma; I've tried to use stack again, pointing it to the exact same code for validation-0.5.1, to no avail), the result is always the same - the library compiles, the test suite doesn't.

Trac metadata

Trac field	Value
Version	7.10.2
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Compiler
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

Similar bugs were closed because of lack of reproducability (#9584 (closed), #7958 (closed)), but I can reproduce your problem.

• clone https://github.com/marcinmrotek/pipes-key-value-csv at commit 5719db5cc7eeecf2a0690ca5627ae6bd9500280c
• uncommented the line -- . KV.foldHeader in test/Test/KeyValue.hs
• cabal install --dependencies-only
• cabal test

I used the following tools:

• ghc-7.10.2
• cabal-install version 1.22.6.0
• version 1.22.4.0 of the Cabal library
• packages from http://www.stackage.org/snapshot/lts-3.4

Attached file keyvalue.cabal (download).

Attached file KeyValue.hs ($1134).

Attached file Vinyl.hs ($1135).

Attached file T10934.hs ($1136).

changed weight to 7

Reproducible with HEAD (ghc-7.11.20151002), see attachments. The cabal file doesn't pull in any dependencies.

$ cabal configure
...

$ cabal build
Building keyvalue-0.0.0.0...
Preprocessing library keyvalue-0.0.0.0...
[1 of 2] Compiling Vinyl            ( Vinyl.hs, dist/build/Vinyl.o )
[2 of 2] Compiling KeyValue         ( KeyValue.hs, dist/build/KeyValue.o )
In-place registering keyvalue-0.0.0.0...

$ ghc -package-db dist/package.conf.inplace -O -fforce-recomp -c T10934.hs
/home/thomas/T10934/dist/build/KeyValue.hi
Declaration for missing1:
  Iface type variable out of scope:  k
Cannot continue after interface file error

Note that the cabal build step is needed to trigger the bug. Running ghc --make -O -outputdir=/tmp -fforce-recomp T10934.hs works fine.

Compiling KeyValue.hs with -dcore-lint results in Core Lint errors:

$ ghc -O -outputdir=/tmp -dcore-lint -fforce-recomp KeyValue.hs
[1 of 2] Compiling Vinyl            ( Vinyl.hs, /tmp/Vinyl.o )
[2 of 2] Compiling KeyValue         ( KeyValue.hs, /tmp/KeyValue.o )
*** Core Lint errors : in result of Simplifier ***
KeyValue.hs:20:19: Warning:
    [in body of lambda with binder f_aBJ :: k_aBI -> *]
    @ (k_aBI :: BOX) is out of scope

Commenting out the PolyKinds extension in KeyValue.hs makes the bug go away.

Trac metadata

Trac field	Value
Priority	normal → high

Very good! Patch coming.

mentioned in commit 0e169a8b

changed milestone to %7.10.3

Trac metadata

Trac field	Value
Test case	- → polykinds/T10934

added 1 deleted label

Thanks! Just for the record, in case someone runs into a similar problem: a "workaround" for this bug in the particular case I've posted was just to remove the offending type class, as its method can be implemented by just having a regular function pattern match on Rec.

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

removed 1 deleted label

added compiler crash label

added Phigh label