Opened 3 years ago

Closed 2 years ago

Last modified 2 years ago

#5445 closed bug (fixed)

programatica package compilation fails

Reported by: maeder Owned by:
Priority: normal Milestone: 7.4.1
Component: Compiler Version: 7.2.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: GHC rejects valid program Difficulty:
Test Case: Blocked By:
Blocking: Related Tickets:

Description

cabal install http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/src-distribution/programatica-1.0.0.2.tar.gz

fails for ghc-7.2.1 with:

 [201 of 223] Compiling PropPlogic       ( property/parse2/Parser/PropPlogic.hs, dist/build/PropPlogic.o )

property/parse2/Parser/PropPlogic.hs:36:25:
    Couldn't match type `PosName.HsName' with `HsName'
    When using functional dependencies to combine
      HasPropStruct
        (PropSyntaxRec.AssertionI i) (PropSyntaxRec.PropPA i),
        arising from the dependency `rec -> prop'
        in the instance declaration at property/syntax/PropSyntaxRec.hs:38:10
      HasPropStruct
        Assertion
        (HsPropStruct.PA
           HsName
           (PropSyntaxRec.HsExpI PosName.HsName)
           HsQualType
           Assertion
           (PropSyntaxRec.PredicateI PosName.HsName)),
        arising from a use of `quant'
        at property/parse2/Parser/PropPlogic.hs:36:25-29
    In the first argument of `(#)', namely `quant q n optt'
    In the expression: quant q n optt # prop p
...

but succeeds for ghc-7.0.4 and ghc-7.2.0.20110728

Change History (8)

comment:1 Changed 3 years ago by simonpj

  • Owner set to simonpj

Nice catch thank you. Am fixing.

comment:2 Changed 3 years ago by simonpj@…

commit faadd61ef05e8f84a2ad7e0fb6b6d873a7b8c232

Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Fri Sep 2 09:20:45 2011 +0100

    Two bugs in rnExports (fixes Trac #5445)
    
    When constructing export lists, data families pose an awkward problem,
    documented in Note [Exports of data families] in RnNames.  Consider
    
    	   module M where
                 import X( D )
                 data instance D Int = M1 | M2
    
    Here M exports M1 and M2, obviously, but does it export D?  It would
    not usually do so, but if we don't then no one can import M selectively
    like this:
               import M( D(M1,M2) )
    
    So we compromise and export D too.  But I made two mistakes
    
    a) Didn't check for conflicts between the extra export of X.D
       and any other exports called "D"
    
    b) Did the extra export for imported things too, not just ones defined
       in this module (ie made the compromise apply much more widely than
       necessary)
    
    This made Programatica (a complex project) break in an obscure
    way; (b) caused an export conflict, (a) meant that the conflict
    was not spotted, which in turn caused later chaos.
    
    Anyway the fix is easy, and is documented in the Note.

 compiler/rename/RnNames.lhs |   73 ++++++++++++++++++++++++++----------------
 1 files changed, 45 insertions(+), 28 deletions(-)

comment:3 Changed 3 years ago by simonpj

  • Resolution set to fixed
  • Status changed from new to closed

I backtracked! Anyway, the bug is fixed. Thank you for identifying it for me.

commit f5c0851a72f7a9cb8a7349eec7a6d4262be7295d
Author: Simon Peyton Jones <simonpj@microsoft.com>
Date:   Fri Sep 2 17:34:00 2011 +0100

    Backtrack on the wierd special case of data family exports
    
    I had second thoughts on the "data family export" question.
    Rather than add a wierd special case it seems better to be
    simple and consistent.  So this patch
    
     * Reverts to the simple behaviour:
         module M where { ... }
       exports only what is defined in M, ie NOT any
       imported data families.
       See Note [Exports of data families] in RnNames
    
    * Documents this behaviour in the user manual, and clarifies
      what was there before.

comment:4 follow-up: Changed 2 years ago by maeder

  • Owner simonpj deleted
  • Resolution fixed deleted
  • Status changed from closed to new

I get the same failure with ghc-7.2.1.20111103. Wasn't the patch merged?

comment:5 in reply to: ↑ 4 Changed 2 years ago by simonmar

  • Milestone set to 7.4.1
  • Resolution set to fixed
  • Status changed from new to closed

Replying to maeder:

I get the same failure with ghc-7.2.1.20111103. Wasn't the patch merged?

No - we're only fixing critical bugs with no workarounds in 7.2.2, and as I understand it this one has workarounds (moreover the fix isn't small).

comment:6 Changed 2 years ago by maeder

I tried to qualify names, but did not find a workaround.

comment:7 Changed 2 years ago by simonmar

I think the workaround is to use explicit export lists (see Simon's commits above).

Note: See TracTickets for help on using tickets.