1. 29 Nov, 2018 5 commits
    • mayac's avatar
      Fix #15828, from `More explicit foralls` · fe57a5ba
      mayac authored
      Summary:
      Fix a bug in commit 12eeb9 which permits the following:
      
      ```
      class C a where
        type T a b
      instance C (Maybe a) where
        type forall a b. T (Maybe a) b = b
      ```
      
      where instead, the user should write:
      
      ```
      instance C (Maybe a) where
        type forall b. T (Maybe a) b = b
      ```
      
      Update the users guide to discuss scoping of type variables in
      explicit foralls in type family instances.
      
      Test Plan: validate
      
      Reviewers: bgamari, goldfire, monoidal
      
      Reviewed By: goldfire
      
      Subscribers: monoidal, rwbarton, carter
      
      GHC Trac Issues: #15828
      
      Differential Revision: https://phabricator.haskell.org/D5283
      fe57a5ba
    • Simon Peyton Jones's avatar
      Taming the Kind Inference Monster · 2257a86d
      Simon Peyton Jones authored
      My original goal was (Trac #15809) to move towards using level numbers
      as the basis for deciding which type variables to generalise, rather
      than searching for the free varaibles of the environment.  However
      it has turned into a truly major refactoring of the kind inference
      engine.
      
      Let's deal with the level-numbers part first:
      
      * Augment quantifyTyVars to calculate the type variables to
        quantify using level numbers, and compare the result with
        the existing approach.  That is; no change in behaviour,
        just a WARNing if the two approaches give different answers.
      
      * To do this I had to get the level number right when calling
        quantifyTyVars, and this entailed a bit of care, especially
        in the code for kind-checking type declarations.
      
      * However, on the way I was able to eliminate or simplify
        a number of calls to solveEqualities.
      
      This work is incomplete: I'm not /using/ level numbers yet.
      When I subsequently get rid of any remaining WARNings in
      quantifyTyVars, that the level-number answers differ from
      the current answers, then I can rip out the current
      "free vars of the environment" stuff.
      
      Anyway, this led me into deep dive into kind inference for type and
      class declarations, which is an increasingly soggy part of GHC.
      Richard already did some good work recently in
      
         commit 5e45ad10
         Date:   Thu Sep 13 09:56:02 2018 +0200
      
          Finish fix for #14880.
      
          The real change that fixes the ticket is described in
          Note [Naughty quantification candidates] in TcMType.
      
      but I kept turning over stones. So this patch has ended up
      with a pretty significant refactoring of that code too.
      
      Kind inference for types and classes
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      * Major refactoring in the way we generalise the inferred kind of
        a TyCon, in kcTyClGroup.  Indeed, I made it into a new top-level
        function, generaliseTcTyCon.  Plus a new Note to explain it
        Note [Inferring kinds for type declarations].
      
      * We decided (Trac #15592) not to treat class type variables specially
        when dealing with Inferred/Specified/Required for associated types.
        That simplifies things quite a bit. I also rewrote
        Note [Required, Specified, and Inferred for types]
      
      * Major refactoring of the crucial function kcLHsQTyVars:
        I split it into
             kcLHsQTyVars_Cusk  and  kcLHsQTyVars_NonCusk
        because the two are really quite different. The CUSK case is
        almost entirely rewritten, and is much easier because of our new
        decision not to treat the class variables specially
      
      * I moved all the error checks from tcTyClTyVars (which was a bizarre
        place for it) into generaliseTcTyCon and/or the CUSK case of
        kcLHsQTyVars.  Now tcTyClTyVars is extremely simple.
      
      * I got rid of all the all the subtleties in tcImplicitTKBndrs. Indeed
        now there is no difference between tcImplicitTKBndrs and
        kcImplicitTKBndrs; there is now a single bindImplicitTKBndrs.
        Same for kc/tcExplicitTKBndrs.  None of them monkey with level
        numbers, nor build implication constraints.  scopeTyVars is gone
        entirely, as is kcLHsQTyVarBndrs. It's vastly simpler.
      
        I found I could get rid of kcLHsQTyVarBndrs entirely, in favour of
        the bnew bindExplicitTKBndrs.
      
      Quantification
      ~~~~~~~~~~~~~~
      * I now deal with the "naughty quantification candidates"
        of the previous patch in candidateQTyVars, rather than in
        quantifyTyVars; see Note [Naughty quantification candidates]
        in TcMType.
      
        I also killed off closeOverKindsCQTvs in favour of the same
        strategy that we use for tyCoVarsOfType: namely, close over kinds
        at the occurrences.
      
        And candidateQTyVars no longer needs a gbl_tvs argument.
      
      * Passing the ContextKind, rather than the expected kind itself,
        to tc_hs_sig_type_and_gen makes it easy to allocate the expected
        result kind (when we are in inference mode) at the right level.
      
      Type families
      ~~~~~~~~~~~~~~
      * I did a major rewrite of the impenetrable tcFamTyPats. The result
        is vastly more comprehensible.
      
      * I got rid of kcDataDefn entirely, quite a big function.
      
      * I re-did the way that checkConsistentFamInst works, so
        that it allows alpha-renaming of invisible arguments.
      
      * The interaction of kind signatures and family instances is tricky.
          Type families: see Note [Apparently-nullary families]
          Data families: see Note [Result kind signature for a data family instance]
                         and Note [Eta-reduction for data families]
      
      * The consistent instantation of an associated type family is tricky.
        See Note [Checking consistent instantiation] and
            Note [Matching in the consistent-instantation check]
        in TcTyClsDecls.  It's now checked in TcTyClsDecls because that is
        when we have the relevant info to hand.
      
      * I got tired of the compromises in etaExpandFamInst, so I did the
        job properly by adding a field cab_eta_tvs to CoAxBranch.
        See Coercion.etaExpandCoAxBranch.
      
      tcInferApps and friends
      ~~~~~~~~~~~~~~~~~~~~~~~
      * I got rid of the mysterious and horrible ClsInstInfo argument
        to tcInferApps, checkExpectedKindX, and various checkValid
        functions.  It was horrible!
      
      * I got rid of [Type] result of tcInferApps.  This list was used
        only in tcFamTyPats, when checking the LHS of a type instance;
        and if there is a cast in the middle, the list is meaningless.
        So I made tcInferApps simpler, and moved the complexity
        (not much) to tcInferApps.
      
        Result: tcInferApps is now pretty comprehensible again.
      
      * I refactored the many function in TcMType that instantiate skolems.
      
      Smaller things
      
      * I rejigged the error message in checkValidTelescope; I think it's
        quite a bit better now.
      
      * checkValidType was not rejecting constraints in a kind signature
           forall (a :: Eq b => blah). blah2
        That led to further errors when we then do an ambiguity check.
        So I make checkValidType reject it more aggressively.
      
      * I killed off quantifyConDecl, instead calling kindGeneralize
        directly.
      
      * I fixed an outright bug in tyCoVarsOfImplic, where we were not
        colleting the tyvar of the kind of the skolems
      
      * Renamed ClsInstInfo to AssocInstInfo, and made it into its
        own data type
      
      * Some fiddling around with pretty-printing of family
        instances which was trickier than I thought.  I wanted
        wildcards to print as plain "_" in user messages, although
        they each need a unique identity in the CoAxBranch.
      
      Some other oddments
      
      * Refactoring around the trace messages from reportUnsolved.
      * A bit of extra tc-tracing in TcHsSyn.commitFlexi
      
      This patch fixes a raft of bugs, and includes tests for them.
      
       * #14887
       * #15740
       * #15764
       * #15789
       * #15804
       * #15817
       * #15870
       * #15874
       * #15881
      2257a86d
    • David Eichmann's avatar
      Hadrian: support dynamically linking ghc · 79d5427e
      David Eichmann authored
      * (#15837 point 5) Use the -rpath gcc option and using the $ORIGIN
      variable which the dynamic linker sets to the location of the ghc
      binary.
      * (#15837 point 4) "-fPIC -dynamic" options are used when building ghc
      when either ghc or the rts have a dynamic way.
      * (#15837 point 7) "-shared -dynload deploy" options are only used when
      linking a library (no longer when linking a program).
      
      Reviewers: bgamari, alpmestan
      
      Reviewed By: alpmestan
      
      Subscribers: adamse, rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5281
      79d5427e
    • Alp Mestanogullari's avatar
      Hadrian: bump Cabal submodule, install extra dynamic flavours of RTS · fb997160
      Alp Mestanogullari authored
      Previously, Hadrian was building all the appropriate dynamic ways for
      libHSrts
      but they were not picked up and installed in the package database when
      we register the rts library. Since we use Cabal for registering
      packages and
      the .cabal files of packages as sources of truth for configuring and
      installing,
      we ended up patching Cabal to add a new field,
      'extra-dynamic-library-flavours',
      to specify those extra flavours to install in .cabal files:
      
          https://github.com/haskell/cabal/pull/5606
      
      We now make use of this in rts.cabal.in to expose dynamic flavours
      behind a
      Cabal flag, which Hadrian will use whenever we are building a GHC
      flavour that
      requires dynamic libraries.
      
      This is all part of a larger plan to build a dynamic stage 2 GHC by
      default,
      like with make, which in turn will fix a lot of test failures. See
      
      Test Plan:
      hadrian/build.sh _build/stage1/lib/package.conf.d/rts-1.0.conf
      _build/stage1/lib/x86_64-.../ should contain many libHSrts-*.so
      
      Reviewers: snowleopard, DavidEichmann, bgamari, erikd, simonmar
      
      Reviewed By: snowleopard, DavidEichmann
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15837
      
      Differential Revision: https://phabricator.haskell.org/D5385
      fb997160
    • Simon Peyton Jones's avatar
      Test Trac #15943 · 1235ca95
      Simon Peyton Jones authored
      This test seems to work in HEAD
      1235ca95
  2. 28 Nov, 2018 2 commits
    • Simon Peyton Jones's avatar
      Comments only · e08d34bb
      Simon Peyton Jones authored
      e08d34bb
    • Sebastian Graf's avatar
      Add Note [Dead case binders in -O0] · 4c8bf63b
      Sebastian Graf authored
      After reverting Phab:D5358, Simon (Peyton Jones) asked for a Note
      summarising why we want to keep the dead case binder check in `cgCase`.
      
      Summary from mail conversation:
      
      * Phab:D5324 means that we no longer /recompute/ dead-ness of case-binders in
        STG-land
      
      * But TidyPgm preserves dead-ness info (see CoreTidy.tidyIdBndr)
      
      * And so we can take advantage of it to avoid a redundant load. This load
        would be eliminated by CmmSink, but that only happens with -O
      4c8bf63b
  3. 27 Nov, 2018 1 commit
    • Alp Mestanogullari's avatar
      Hadrian: improve bindist rule · 8f52ab92
      Alp Mestanogullari authored
      As outlined in #15925, hadrian bindists had not made a clear choice with
      respect to relocatable GHCs and wrapper scripts. This commit implements
      the policy described in the ticket. That is:
      
      - the bindists ship {bin, lib} as they are, modulo the addition of
        haddock from stage2/bin
      - we now _always_ generate wrapper scripts for all the programs that
        are in the bindist's bin/ directory
      
      The idea being that anyone on Linux/Windows/OS X can just unpack
      the binary distribution anywhere and start using bin/ghc, while the
      installation process systematicaly generates wrapper scripts.
      
      Test Plan: hadrian/build.sh binary-dist ; cd
      _build/bindist/ghc-X.Y.Z-arch/; configure --prefix=/tmp/foo && make
      install
      
      Reviewers: snowleopard, bgamari, angerman
      
      Reviewed By: snowleopard, bgamari, angerman
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15925
      
      Differential Revision: https://phabricator.haskell.org/D5371
      8f52ab92
  4. 26 Nov, 2018 5 commits
    • Ryan Scott's avatar
      Fix #15941 by only special-casing visible infix applications · 984b75de
      Ryan Scott authored
      Summary:
      The iface pretty-printer had a special case for an
      application of an infix type constructor to two arguments. But this
      didn't take the visibilities of the arguments into account, which
      could lead to strange output like `@{LiftedRep} -> @{LiftedRep}` when
      `-fprint-explicit-kinds` was enabled (#15941). The fix is relatively
      straightforward: simply plumb through the visibilities of each
      argument, and only trigger the special case for infix applications
      if both arguments are visible (i.e., required).
      
      Test Plan: make test TEST=T15941
      
      Reviewers: goldfire, bgamari, monoidal
      
      Reviewed By: goldfire, monoidal
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #15941
      
      Differential Revision: https://phabricator.haskell.org/D5375
      984b75de
    • Ryan Scott's avatar
      Use autoconf to generate version numbers for libiserv and friends · 8f9f52d8
      Ryan Scott authored
      Summary:
      Currently, the version numbers for `libiserv`, `iserv`, and
      `iserv-proxy` are hard-coded directly into their `.cabal` files.
      These are easy to forget to update, and in fact, this has already
      happened once (see #15866). Let's use `autoconf` to do this for us
      so that it is not forgotten in the future.
      
      Test Plan: ./validate
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, erikd, carter
      
      GHC Trac Issues: #15866
      
      Differential Revision: https://phabricator.haskell.org/D5302
      8f9f52d8
    • Ryan Scott's avatar
      Print explicit foralls in type family eqns when appropriate · f932b1aa
      Ryan Scott authored
      Summary:
      When `-fprint-explicit-foralls` is enabled, type family
      equations are either printed without an explict `forall` entirely,
      or with a bizarre square bracket syntax (in the case of closed type
      families). I find neither satisfying, so in this patch, I introduce
      support for printing explicit `forall`s in open type-family, closed
      type-family, and data-family equations when appropriate. (By "when
      appropriate", I refer to the conditions laid out in
      `Note [When to print foralls]` in `IfaceType`.)
      
      One tricky point in the implementation is that I had to pick a
      visibility for each type variable in a `CoAxiom`/`FamInst` in order
      to be able to pass it to `pprUserIfaceForAll` //et al.// Because
      the type variables in a type family instance equation can't be
      instantiated by the programmer anyway, the choice only really matters
      for pretty-printing purposes, so I simply went with good ol'
      trustworthy `Specified`. (This design choice is documented in
      `Note [Printing foralls in type family instances]` in `IfaceType`.)
      
      Test Plan: make test TEST=T15827
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, carter
      
      GHC Trac Issues: #15827
      
      Differential Revision: https://phabricator.haskell.org/D5282
      f932b1aa
    • Ömer Sinan Ağacan's avatar
      Fix build on darwin · df570d92
      Ömer Sinan Ağacan authored
      CPP error introduced with b2950e03
      df570d92
    • Ömer Sinan Ağacan's avatar
      Revert "Remove redundant check in cgCase" · 8a6aa877
      Ömer Sinan Ağacan authored
      This reverts commit d13b7d60.
      
      (See discussion in D5358)
      8a6aa877
  5. 25 Nov, 2018 1 commit
  6. 24 Nov, 2018 5 commits
  7. 23 Nov, 2018 10 commits
  8. 22 Nov, 2018 11 commits