[commit: ghc] master: Axe RecFlag on TyCons. (b8b3e30)

[git at git.haskell.org]

Repository : ssh://git@git.haskell.org/ghc

On branch  : master
Link       : http://ghc.haskell.org/trac/ghc/changeset/b8b3e30a6eedf9f213b8a718573c4827cfa230ba/ghc

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

commit b8b3e30a6eedf9f213b8a718573c4827cfa230ba
Author: Edward Z. Yang <ezyang at cs.stanford.edu>
Date:   Fri Jun 24 11:03:47 2016 -0700

    Axe RecFlag on TyCons.
    
    Summary:
    This commit removes the information about whether or not
    a TyCon is "recursive", as well as the code responsible
    for calculating this information.
    
    The original trigger for this change was complexity regarding
    how we computed the RecFlag for hs-boot files.  The problem
    is that in order to determine if a TyCon is recursive or
    not, we need to determine if it was defined in an hs-boot
    file (if so, we conservatively assume that it is recursive.)
    
    It turns that doing this is quite tricky.  The "obvious"
    strategy is to typecheck the hi-boot file (since we are
    eventually going to need the typechecked types to check
    if we properly implemented the hi-boot file) and just extract
    the names of all defined TyCons from the ModDetails, but
    this actually does not work well if Names from the hi-boot
    file are being knot-tied via if_rec_types: the "extraction"
    process will force thunks, which will force the typechecking
    process earlier than we have actually defined the types
    locally.
    
    Rather than work around all this trickiness (it certainly
    can be worked around, either by making interface loading
    MORE lazy, or just reading of the set of defined TyCons
    directly from the ModIface), we instead opted to excise
    the source of the problem, the RecFlag.
    
    For one, it is not clear if the RecFlag even makes sense,
    in the presence of higher-orderness:
    
        data T f a = MkT (f a)
    
    T doesn't look recursive, but if we instantiate f with T,
    then it very well is!  It was all very shaky.
    
    So we just don't bother anymore.  This has two user-visible
    implications:
    
    1. is_too_recursive now assumes that all TyCons are
    recursive and will bail out in a way that is still mysterious
    to me if there are too many TyCons.
    
    2. checkRecTc, which is used when stripping newtypes to
    get to representation, also assumes all TyCons are
    recursive, and will stop running if we hit the limit.
    
    The biggest risk for this patch is that we specialize less
    than we used to; however, the codeGen tests still seem to
    be passing.
    
    Signed-off-by: Edward Z. Yang <ezyang at cs.stanford.edu>
    
    Reviewers: simonpj, austin, bgamari
    
    Subscribers: goldfire, thomie
    
    Differential Revision: https://phabricator.haskell.org/D2360


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

b8b3e30a6eedf9f213b8a718573c4827cfa230ba
 compiler/basicTypes/DataCon.hs                 |   5 +-
 compiler/iface/BuildTyCl.hs                    |   5 +-
 compiler/iface/IfaceSyn.hs                     |  30 +---
 compiler/iface/MkIface.hs                      |   5 +-
 compiler/iface/TcIface.hs                      |   8 +-
 compiler/prelude/TysWiredIn.hs                 |  49 +++---
 compiler/specialise/SpecConstr.hs              |   8 +-
 compiler/typecheck/TcInstDcls.hs               |   2 +-
 compiler/typecheck/TcTyClsDecls.hs             |  44 +++--
 compiler/typecheck/TcTyDecls.hs                | 234 +------------------------
 compiler/types/TyCon.hs                        |  25 +--
 compiler/vectorise/Vectorise/Generic/PData.hs  |   3 -
 compiler/vectorise/Vectorise/Type/TyConDecl.hs |  11 +-
 13 files changed, 79 insertions(+), 350 deletions(-)

Diff suppressed because of size. To see it, use:

    git diff-tree --root --patch-with-stat --no-color --find-copies-harder --ignore-space-at-eol --cc b8b3e30a6eedf9f213b8a718573c4827cfa230ba