makeCorePair: arity missing

when compiling our hets sources with optimization I get unexpected messages like:

makeCorePair: arity missing $cmap_sentence{v au5bz} [lid]
makeCorePair: arity missing $cmap_symbol{v au5bC} [lid]

I think it is emitted by the desugarer i.e. for the source file http://trac.informatik.uni-bremen.de:8080/hets/browser/trunk/Comorphisms/OWL2CommonLogic.hs

I've noticed no consequences (bugs), though. Maybe it should only be emitted when a certain verbosity level is set.

Trac metadata

Trac field	Value
Version	7.0.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

changed milestone to %7.2.1

changed weight to 7

Thanks for the report.

pprTrace looks like a very suspicious function to me. I'm not sure it ever makes sense to use it. Maybe -dno-debug-output should default to on unless in a -DDEBUG compiler?

Trac metadata

Trac field	Value
Priority	normal → high

I think having -dno-debug-output default to on is a very good idea. What do you mean by pprTrace being suspicious? Just the same reasons that trace is suspicious?

I mean that, with -dno-debug-output off by default, I can't imagine a use of it that would make sense.

There's definitely something wrong, although it's harmless I think. However

• It's hard for me to reproduce because I don't much want to go through the process of building all of Hets
• It's to do with default methods, which is being up-heaved by Pedro anyway

I think the best thing to do is to wait for 7.2, and try again then.

Meanwhile if you felt able to cut it down to a test case that'd be even better, but you may not want to bother since it's doing no harm meanwhile.

Simon

While checking another bug I've come across this one. Small example:

module M1 where

class MyEnum a where
  myEnum :: [a]

instance MyEnum () where
  {-# INLINABLE myEnum #-}
  myEnum = [()]

module M2 where

import M1

{-# SPECIALISE myEnum  :: [()] #-}

Compiling with HEAD gives:

~/bugs/ghc/4227 0 > ~/dev/ghc/inplace/bin/ghc-stage2 --make -O -fforce-recomp M2
[1 of 2] Compiling M1               ( M1.hs, M1.o )
[2 of 2] Compiling M2               ( M2.hs, M2.o )
makeCorePair: arity missing myEnum{v dcc} [lid]

Interestingly if I move the SPECIALISE pragma into M1 module, there is no warning:

module M1 where

class MyEnum a where
  myEnum :: [a]

instance MyEnum () where
  {-# INLINABLE myEnum #-}
  myEnum = [()]

{-# SPECIALISE myEnum  :: [()] #-}

~/bugs/ghc/4227 0 > ~/dev/ghc/inplace/bin/ghc-stage2 --make -O -fforce-recomp M1
[1 of 1] Compiling M1               ( M1.hs, M1.o )

mentioned in commit 777b8c4b

closed

I investigated michaelt's example. Your SPECIALISE pragmas for myEnum in M2 is for the class method

myEnum :: MyEnum a => [a]

But the class method is just a record selector, so specialising it doesn't make much sense. (The reason for the bleating message is related to it being a class method too, but that's an implementation detail.) So I've arranged to give a more helpful message if you try to specialise a class method.

commit 777b8c4bd6f8a76f2fd365aa43451b7af098e9ef
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Mon Jun 13 15:03:38 2011 +0100

    Don't allow specialisation of class methods (fixes Trac #5001)
    
    It doesn't make sense to specialise class methods -- their
    code is simply a record selector.  Moreover, such methods
    don't (currently) have an inl_sat field in their InlinePragma
    which made DsBinds.makeCoreArity bleat.
    
    This patch just ignores such pragmas, with a warning.

>---------------------------------------------------------------

 compiler/deSugar/DsBinds.lhs |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

That done, I'm closing the ticket.

Simon

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

reopened

The messages of the initial description still turn up with ghc-7.2.0.20110728

Trac metadata

Trac field	Value
Resolution	ResolvedFixed → Unresolved

Replying to [ticket:5001#comment:53504 maeder]:

The messages of the initial description still turn up with ghc-7.2.0.20110728

Probably the patch just wasn't merged to the 7.2 branch.

changed milestone to %7.4.1

The link in the summary seems to be broken. Can you give us instructions for how to reproduce the problem, please?

closed

No testcase, so closing.

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedInvalid

reopened