1. 03 Dec, 2018 4 commits
    • Simon Peyton Jones's avatar
      Introduce tcTypeKind, and use it · 03d48526
      Simon Peyton Jones authored
      In the type checker Constraint and * are distinct; and the function
      that takes the kind of a type should respect that distinction
      (Trac #15971).
      This patch implements the change:
      * Introduce Type.tcTypeKind, and use it throughout the type
        inference engine
      * Add new Note [Kinding rules for types] for the kinding
        rules, especially for foralls.
      * Redefine
          isPredTy ty = tcIsConstraintKind (tcTypeKind ty)
        (it had a much more complicated definition before)
      Some miscellaneous refactoring
      * Get rid of TyCoRep.isTYPE, Kind.isTYPEApp,
        in favour of TyCoRep.kindRep, kindRep_maybe
      * Rename Type.getRuntimeRepFromKind_maybe
        to getRuntimeRep_maybe
      I did some spot-checks on compiler perf, and it really doesn't
      budge (as expected).
    • Ryan Scott's avatar
      Fix embarrassing infinite loop in pprParendType · 89d80921
      Ryan Scott authored
      `pprParendType` was missing an explicit case for
      `EqualityT`, which caused it to fall through to a catch-all case
      that invokes `ppr`. But `ppr` itself does not have a case for a
      partial application of `EqualityT`, so //it// falls back to
      `pprParendType`, resulting in an infinite loop!
      The fix is simple: add a case for `EqualityT` in `pprParendType`.
      While I was in the neighborhood, I removed the catch-call case in
      `pprParendType` to make this sort of mistake less likely to happen
      in the future.
      Test Plan: make test TEST=T15985
      Reviewers: bgamari, monoidal, simonpj
      Reviewed By: monoidal, simonpj
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15985
      Differential Revision: https://phabricator.haskell.org/D5403
    • Ryan Scott's avatar
      Fix #15954 by rejigging check_type's order · 2e6cc3d0
      Ryan Scott authored
      Previously, `check_type` (which catches illegal uses of
      unsaturated type synonyms without enabling `LiberalTypeSynonyms`,
      among other things) always checks for uses of polytypes before
      anything else. There is a problem with this plan, however:
      checking for polytypes requires decomposing `forall`s and other
      invisible arguments, an action which itself expands type synonyms!
      Therefore, if we have something like:
      type A a = Int
      type B (a :: Type -> Type) = forall x. x -> x
      type C = B A
      Then when checking `B A`, `A` will get expanded to `forall x. x -> x`
      before `check_type` has an opportunity to realize that `A` is an
      unsaturated type synonym! This is the root cause of #15954.
      This patch fixes the issue by moving the case of `check_type` that
      detects polytypes to be //after// the case that checks for
      `TyConApp`s. That way, the `TyConApp` case will properly flag things
      like the unsaturated use of `A` in the example above before we ever
      attempt to check for polytypes.
      Test Plan: make test TEST=T15954
      Reviewers: simonpj, bgamari, goldfire
      Reviewed By: simonpj
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15954
      Differential Revision: https://phabricator.haskell.org/D5402
    • Alec Theriault's avatar
      Warn on all out-of-range literals in pats/exprs · 75a8349b
      Alec Theriault authored
      These changes were motivated by #13256. While poking around, I
      realized we weren't very consistent in our "-Woverflowed-literals"
      warnings. This patch fixes that by:
        * warning earlier on in the pipeline (ie. before we've desugared
          'Int' patterns into 'I# Int#')
        * handling 'HsLit' as well as 'HsOverLit' (this covers unboxed
        * covering more pattern / expression forms
      4/6 of the warnings in the 'Overflow' test are due to this patch. The
      other two are mostly for completeness.
      Also fixed a missing empty-enumeration warning for 'Natural'.
      This warnings were tripped up by the 'Bounded Word' instance (see #9505),
      but the fix was obvious and simple: use unboxed word literals.
      Test Plan: make TEST=Overflow && make TEST=T10930
      Reviewers: hvr, bgamari, RyanGlScott
      Reviewed By: RyanGlScott
      Subscribers: RyanGlScott, rwbarton, carter
      GHC Trac Issues: #13256, #10930
      Differential Revision: https://phabricator.haskell.org/D5181
  2. 02 Dec, 2018 1 commit
    • Alp Mestanogullari's avatar
      update (CicleCI) CI script to work with ghc-ci · 93a3f907
      Alp Mestanogullari authored
      ghc-ci is a tiny webservice that acts as an intermediate between our
      CircleCI jobs on Gitlab and the actual builds running on CircleCI, so that
      the build script doesn't need to rely on any secret, which makes the whole
      setup fork-friendly.
      The concrete effect of this patch is to allow any fork of GHC on Gitlab to
      run CircleCI jobs.
  3. 01 Dec, 2018 6 commits
  4. 30 Nov, 2018 5 commits
    • David Eichmann's avatar
      Skip all performance tests if not in a git repo. · 6e24a0be
      David Eichmann authored
      Reviewers: bgamari, tdammers, osa1
      Reviewed By: tdammers
      Subscribers: osa1, tdammers, rwbarton, carter
      GHC Trac Issues: #15923
      Differential Revision: https://phabricator.haskell.org/D5367
    • Sebastian Graf's avatar
      Deduplicate decision to count thunks in `-ticky` · f10df65f
      Sebastian Graf authored
      Previously, the logic that checks whether a thunk has a counter or not
      was duplicated in multiple functions.
      This led to thunk enters being accounted to their enclosing functions in
      `StgCmmTicky.tickyEnterThunk`, because the outer call to
      `withNewTickyCounterThunk` didn't set the counter label for the thunk.
      And rightly so! `tickyEnterThunk` should only account thunk enters to a
      counter if `-ticky-dyn-thunk` is on.
      This patch extracts the logic that was already present in its most
      general form in `withNewTickyCounterThunk` into its own functions and
      lets all other call sites checking for `-ticky-dyn-thunk` call this new
      function named `thunkHasCounter` instead.
      Reviewers: bgamari, simonmar
      Reviewed By: simonmar
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5392
    • Alec Theriault's avatar
      Add 'Lift' instances for 'NonEmpty' and 'Void' · 47875bd4
      Alec Theriault authored
      Since 'NonEmpty' and 'Void' are now part of 'base', it makes
      sense that we put 'Lift' instances for them in 'template-haskell'.
      Not doing so is going to force users to define their own (possibly
      colliding) orphan instances downstream.
      Test Plan: ./validate
      Reviewers: goldfire, bgamari, RyanGlScott
      Reviewed By: RyanGlScott
      Subscribers: RyanGlScott, rwbarton, carter
      GHC Trac Issues: #15961
      Differential Revision: https://phabricator.haskell.org/D5391
    • Simon Peyton Jones's avatar
      Two tests for Trac #14230 · 80d665a1
      Simon Peyton Jones authored
    • Ryan Scott's avatar
      Accept T15828 test output · b1af0aed
      Ryan Scott authored
      This test output changed slightly due to commit
      2257a86d (which is expected).
  5. 29 Nov, 2018 10 commits
    • Chaitanya Koparkar's avatar
      Add a test case for #15962 · 8d7496c4
      Chaitanya Koparkar authored
      Test Plan: make test TEST=T15962
      Reviewers: RyanGlScott, bgamari
      Reviewed By: RyanGlScott
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15962
      Differential Revision: https://phabricator.haskell.org/D5393
    • Ryan Scott's avatar
      Make ghc-in-ghci support Hadrian · 30a363ae
      Ryan Scott authored
      Currently, `ghc-in-ghci` is hard-coded to only support
      the installation path of the `make`-based build system. There isn't
      a fundamental reason why this must be the case, however—it's just a
      matter of communicating which directories to look into.
      For the time being, I've hacked `utils/ghc-in-ghci/run.sh` to just
      check the default Hadrian installation path in addition to the `make`
      one. Disclaimer: I'm not well-versed in `bash`-fu, so it's possible
      that there is a better way to accomplish what I'm setting out to do.
      Suggestions welcome.
      Test Plan: ./utils/ghc-in-ghci/run.sh
      Reviewers: alpmestan, bgamari
      Reviewed By: alpmestan
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5390
    • Ryan Scott's avatar
      Allow containers-0.6, QuickCheck-2.12 in Hadrian · 8bffd580
      Ryan Scott authored
      Currently, Hadrian has restrictive upper bounds on
      `containers` and `QuickCheck` that prevents it from building with
      the latest versions of each respective library ( and There doesn't appear to be any good reason to do so,
      since Hadrian builds fine with them, so let's bump the upper version
      bounds accordingly.
      Test Plan: ./build/hadrian.sh
      Reviewers: bgamari, alpmestan, snowleopard
      Reviewed By: snowleopard
      Subscribers: rwbarton, carter
      Differential Revision: https://phabricator.haskell.org/D5389
    • Chaitanya Koparkar's avatar
      Fix #15953 by consistently using dumpIfSet_dyn to print debug output · dcf1f926
      Chaitanya Koparkar authored
      In some modules we directly dump the debugging output to STDOUT
      via 'putLogMsg', 'printInfoForUser' etc. However, if `-ddump-to-file`
      is enabled, that output should be written to a file. Easily fixed.
      Certain tests (T3017, Roles3, T12763 etc.) expect part of the
      output generated by `-ddump-types` to be in 'PprUser' style. However,
      generally we want all other debugging output to use 'PprDump'
      style. `traceTcRn` and `traceTcRnForUser` help us accomplish this.
      This patch also documents some missing flags in the users guide.
      Reviewers: RyanGlScott, bgamari, hvr
      Reviewed By: RyanGlScott
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15953
      Differential Revision: https://phabricator.haskell.org/D5382
    • Victor Nawothnig's avatar
      Add missing since annotations · 9e3aaf8b
      Victor Nawothnig authored
      Reviewers: hvr, bgamari, RyanGlScott
      Reviewed By: RyanGlScott
      Subscribers: RyanGlScott, rwbarton, carter
      GHC Trac Issues: #15930
      Differential Revision: https://phabricator.haskell.org/D5379
    • mayac's avatar
      Fix #15828, from `More explicit foralls` · fe57a5ba
      mayac authored
      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
    • 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
      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.
      * 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
      * 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
    • 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
      * (#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
    • 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
      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
      we ended up patching Cabal to add a new field,
      to specify those extra flavours to install in .cabal files:
      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
      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
    • Simon Peyton Jones's avatar
      Test Trac #15943 · 1235ca95
      Simon Peyton Jones authored
      This test seems to work in HEAD
  6. 28 Nov, 2018 2 commits
    • Simon Peyton Jones's avatar
      Comments only · e08d34bb
      Simon Peyton Jones authored
    • 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
      * 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
  7. 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
      Reviewers: snowleopard, bgamari, angerman
      Reviewed By: snowleopard, bgamari, angerman
      Subscribers: rwbarton, carter
      GHC Trac Issues: #15925
      Differential Revision: https://phabricator.haskell.org/D5371
  8. 26 Nov, 2018 5 commits
    • Ryan Scott's avatar
      Fix #15941 by only special-casing visible infix applications · 984b75de
      Ryan Scott authored
      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
    • Ryan Scott's avatar
      Use autoconf to generate version numbers for libiserv and friends · 8f9f52d8
      Ryan Scott authored
      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
    • Ryan Scott's avatar
      Print explicit foralls in type family eqns when appropriate · f932b1aa
      Ryan Scott authored
      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
    • Ömer Sinan Ağacan's avatar
      Fix build on darwin · df570d92
      Ömer Sinan Ağacan authored
      CPP error introduced with b2950e03
    • Ö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)
  9. 25 Nov, 2018 1 commit
  10. 24 Nov, 2018 5 commits