Opened 10 years ago

Closed 10 years ago

Last modified 9 years ago

#3955 closed bug (fixed)

occasional stray "mkUsageInfo" output

Reported by: dmwit Owned by: simonpj
Priority: normal Milestone: 6.12.3
Component: Compiler Version: 6.12.1
Keywords: Cc:
Operating System: Linux Architecture: x86_64 (amd64)
Type of failure: Other Test Case: typecheck/should_compile/T3955
Blocked By: Blocking:
Related Tickets: Differential Rev(s):
Wiki Page:

Description (last modified by igloo)

Sometimes, there is a stray line in the compilation output that looks like

mkUsageInfo: internal name? a{tv a43R}

The letters at the end vary. It doesn't lead to any problems, but is a bit unsightly.

Attachments (2)

mkUsageInfo.hs (87 bytes) - added by dmwit 10 years ago.
a small test case
bug3955.hs (309 bytes) - added by guest 10 years ago.
Same warning with -XGeneralizedNewtypeDeriving

Download all attachments as: .zip

Change History (7)

Changed 10 years ago by dmwit

Attachment: mkUsageInfo.hs added

a small test case

comment:1 Changed 10 years ago by dmwit

Architecture: Unknown/Multiplex86_64 (amd64)
Operating System: Unknown/MultipleLinux
Type of failure: None/UnknownOther

Changed 10 years ago by guest

Attachment: bug3955.hs added

Same warning with -XGeneralizedNewtypeDeriving

comment:2 Changed 10 years ago by simonpj

Owner: set to simonpj

I'm on this.


comment:3 Changed 10 years ago by igloo

Description: modified (diff)
Milestone: 6.12.3

comment:4 Changed 10 years ago by simonpj

Test Case: typecheck/should_compile/T3955

comment:5 Changed 10 years ago by simonpj

Resolution: fixed
Status: newclosed

Fixed by

Fri Apr  9 17:37:10 BST 2010
  * Fix Trac #3955: renamer and type variables
  The renamer wasn't computing the free variables of a type declaration
  properly.  This patch refactors a bit, and makes it more robust,
  fixing #3955 and several other closely-related bugs.  (We were
  omitting some free variables and that could just possibly lead to a
  usage-version tracking error.

    M ./compiler/rename/RnEnv.lhs -3 +11
    M ./compiler/rename/RnSource.lhs -43 +38

Then I made the mkUsageInfo warning into a panic

Thu May  6 17:38:13 BST 2010
  * Make a missing name in mkUsageInfo into a panic
  We really want to know about this!

    M ./compiler/iface/MkIface.lhs -1 +1

But this revealed more bugs:

Thu May  6 17:27:19 BST 2010
  * Make tcg_dus behave more sanely; fixes a mkUsageInfo panic
  The tcg_dus field used to contain *uses* of type and class decls,
  but not *defs*.  That was inconsistent, and it really went wrong
  for Template Haskell bracket.  What happened was that
   foo = [d| data A = A
         	   f :: A -> A
         	   f x = x |]
  would find a "use" of A when processing the top level of the module,
  which in turn led to a mkUsageInfo panic in MkIface.  The cause was
  the fact that the tcg_dus for the nested quote didn't have defs for

    M ./compiler/basicTypes/NameSet.lhs -4 +5
    M ./compiler/rename/RnBinds.lhs -2 +2
    M ./compiler/rename/RnExpr.lhs -4 +5
    M ./compiler/rename/RnSource.lhs -27 +30

plus, I belive,

Thu May  6 17:41:35 BST 2010
  * Find the correct external ids when there's a wrapper
  We were failing to externalise the wrapper id for a function
  that had one.

    M ./compiler/main/TidyPgm.lhs -2 +9

(I'm not 100% sure of what this patch was about!)


Note: See TracTickets for help on using tickets.