[GHC] #14092: hs-boot unfolding visibility not consistent between --make and -c

[GHC]

#14092: hs-boot unfolding visibility not consistent between --make and -c
-------------------------------------+-------------------------------------
        Reporter:  ezyang            |                Owner:  (none)
            Type:  bug               |               Status:  new
        Priority:  normal            |            Milestone:
       Component:  Compiler          |              Version:  8.2.1
      Resolution:                    |             Keywords:  hs-boot
Operating System:  Unknown/Multiple  |         Architecture:
                                     |  Unknown/Multiple
 Type of failure:  None/Unknown      |            Test Case:
      Blocked By:                    |             Blocking:
 Related Tickets:                    |  Differential Rev(s):
       Wiki Page:                    |
-------------------------------------+-------------------------------------
Changes (by duog):

 * keywords:  hs-boot. => hs-boot


Comment:

 Thanks for this explanation ezyang, this is a very tricky area and I think
 I'm finally starting to understand what's going on.

 Note that your first example can be modified to exhibit another bug:
 to A.hs add
 {{{
 h = f
 }}}
 to C.hs change to
 {{{
 g = h 2
 }}}

 This compiles in --make mode, even though C should not be able to see h!

 You say that -c behaviour is correct, and in the sense that it is
 predictable and deterministic, of course you are right. However, the
 current --make behaviour produces code that is at least as good(modulo the
 bug exhibited above), and in your first (A.hs-boot, B.hs, A.hs, C.hs)
 example, it is better! I wonder if it is possible to exploit laziness to
 always have unfoldings available even when importing an .hs-boot.
 trac:13299 seems relevant.

 I am currently working on an idea to split parsing, typechecking,
 simplifying, and codegen for the purpose of allowing more parallelism in
 --make mode. (I have a mostly-working patch, which I hope to have on phab
 this week, although it will be a little untidy). This might allow having
 unfoldings available from .hs-boot imports.

 Regarding "views" into the home package table, I think this may be a
 fruitful idea. It seems to me to offer nice solutions to this ticket, as
 well as trac:9370.

 :pieinthesky:

 I have thought of storing in interface files, instead of an unfolding,
 loosely a "map" of (way, OptimizationSettings)->unfolding. This would
 require the notion of views into the home package table. I think this
 would help address problems such as trac:10923. It would also allow
 eliminating the idea of "way" interfaces (.dyn_hi, .p_hi, etc), with all
 of that information in a single .hi file. I do admit that I'm not sure
 exactly what benefit removing  way interfaces would provide, except that
 it does seem cleaner to me.

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