[GHC] #9562: Type families + hs-boot files = unsafeCoerce

GHC ghc-devs at haskell.org
Fri Apr 10 09:36:45 UTC 2015


#9562: Type families + hs-boot files = unsafeCoerce
-------------------------------------+-------------------------------------
        Reporter:  goldfire          |                   Owner:  ezyang
            Type:  bug               |                  Status:  new
        Priority:  high              |               Milestone:
       Component:  Compiler          |                 Version:  7.8.3
      Resolution:                    |                Keywords:
Operating System:  Unknown/Multiple  |            Architecture:
 Type of failure:  GHC accepts       |  Unknown/Multiple
  invalid program                    |               Test Case:
      Blocked By:                    |                Blocking:
 Related Tickets:  #10270            |  Differential Revisions:
-------------------------------------+-------------------------------------

Comment (by simonpj):

 After discussion with Richard

  * Note that `B` is never imported by anyone!  (Although somehow GHC knows
 to link in `B.o` nevertheless.)

  * If `B` had been imported by some module, then the aggressive type-
 function overlap check would have detected the conflict with `D`.
 (Provided that the optimisation in that check, which avoids checking
 conflicts that have already been checked in some sub-tree, isn't fooled by
 `B.hs-boot`.)

 Possible ways to fix (two variants of the same thing):

  1. GHC should not link and run a program in which `B.hs` is never
 imported (only `B.hs-boot` is).  That'd force the programmer to import
 `B`, and hence the overlap check would fire.

  2. Alternatively, when GHC is preparing the list of modules to send to
 the linker, perform an overlap check on type functions, as if you were
 compiling `module Top where { import Main; import B }`.   Where the "`B`"
 is the module(s) that are never imported by anyone except via `{-# SOURCE
 #-}`.

 Richard likes (2); Simon likes (1).  I'd go with whatever is easier to
 implement.  But in (1) the error message should be clear and explicit.

 Edward: thanks for the offer!

--
Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9562#comment:7>
GHC <http://www.haskell.org/ghc/>
The Glasgow Haskell Compiler


More information about the ghc-tickets mailing list