1. 17 Jun, 2020 4 commits
    • Krzysztof Gogolewski's avatar
      Various performance improvements · 6cb84c46
      Krzysztof Gogolewski authored and Ben Gamari's avatar Ben Gamari committed
      This implements several general performance improvements to GHC,
      to offset the effect of the linear types change.
      
      General optimisations:
      - Add a `coreFullView` function which iterates `coreView` on the
        head. This avoids making function recursive solely because the
        iterate `coreView` themselves. As a consequence, this functions can
        be inlined, and trigger case-of-known constructor (_e.g._
        `kindRep_maybe`, `isLiftedRuntimeRep`, `isMultiplicityTy`,
        `getTyVar_maybe`, `splitAppTy_maybe`, `splitFunType_maybe`,
        `tyConAppTyCon_maybe`). The common pattern about all these functions
        is that they are almost always used as views, and immediately
        consumed by a case expression. This commit also mark them asx `INLINE`.
      - In `subst_ty` add a special case for nullary `TyConApp`, which avoid
        allocations altogether.
      - Use `mkTyConApp` in `subst_ty` for the general `TyConApp`. This
        required quite a bit of module shuffling.
        case. `myTyConApp` enforces crucial sharing, which was lost during
        substitution. See also !2952 .
      - Make `subst_ty` stricter.
      - In `eqType` (specifically, in `nonDetCmpType`), add a special case,
        tested first, for the very common case of nullary `TyConApp`.
        `nonDetCmpType` has been made `INLINE` otherwise it is actually a
        regression. This is similar to the optimisations in !2952.
      
      Linear-type specific optimisations:
      - Use `tyConAppTyCon_maybe` instead of the more complex `eqType` in
        the definition of the pattern synonyms `One` and `Many`.
      - Break the `hs-boot` cycles between `Multiplicity.hs` and `Type.hs`:
        `Multiplicity` now import `Type` normally, rather than from the
        `hs-boot`. This way `tyConAppTyCon_maybe` can inline properly in the
        `One` and `Many` pattern synonyms.
      - Make `updateIdTypeAndMult` strict in its type and multiplicity
      - The `scaleIdBy` gets a specialised definition rather than being an
        alias to `scaleVarBy`
      - `splitFunTy_maybe` is given the type `Type -> Maybe (Mult, Type,
        Type)` instead of `Type -> Maybe (Scaled Type, Type)`
      - Remove the `MultMul` pattern synonym in favour of a view `isMultMul`
        because pattern synonyms appear not to inline well.
      - in `eqType`, in a `FunTy`, compare multiplicities last: they are
        almost always both `Many`, so it helps failing faster.
      - Cache `manyDataConTy` in `mkTyConApp`, to make sure that all the
        instances of `TyConApp ManyDataConTy []` are physically the same.
      
      This commit has been authored by
      * Richard Eisenberg
      * Krzysztof Gogolewski
      * Arnaud Spiwack
      
      Metric Decrease:
          haddock.base
          T12227
          T12545
          T12990
          T1969
          T3064
          T5030
          T9872b
      
      Metric Increase:
          haddock.base
          haddock.Cabal
          haddock.compiler
          T12150
          T12234
          T12425
          T12707
          T13035
          T13056
          T15164
          T16190
          T18304
          T1969
          T3064
          T3294
          T5631
          T5642
          T5837
          T6048
          T9020
          T9233
          T9675
          T9872a
          T9961
          WWRec
      6cb84c46
    • Krzysztof Gogolewski's avatar
      Linear types (#15981) · 40fa237e
      Krzysztof Gogolewski authored and Ben Gamari's avatar Ben Gamari committed
      This is the first step towards implementation of the linear types proposal
      (https://github.com/ghc-proposals/ghc-proposals/pull/111).
      
      It features
      
      * A language extension -XLinearTypes
      * Syntax for linear functions in the surface language
      * Linearity checking in Core Lint, enabled with -dlinear-core-lint
      * Core-to-core passes are mostly compatible with linearity
      * Fields in a data type can be linear or unrestricted; linear fields
        have multiplicity-polymorphic constructors.
        If -XLinearTypes is disabled, the GADT syntax defaults to linear fields
      
      The following items are not yet supported:
      
      * a # m -> b syntax (only prefix FUN is supported for now)
      * Full multiplicity inference (multiplicities are really only checked)
      * Decent linearity error messages
      * Linear let, where, and case expressions in the surface language
        (each of these currently introduce the unrestricted variant)
      * Multiplicity-parametric fields
      * Syntax for annotating lambda-bound or let-bound with a multiplicity
      * Syntax for non-linear/multiple-field-multiplicity records
      * Linear projections for records with a single linear field
      * Linear pattern synonyms
      * Multiplicity coercions (test LinearPolyType)
      
      A high-level description can be found at
      https://ghc.haskell.org/trac/ghc/wiki/LinearTypes/Implementation
      Following the link above you will find a description of the changes made to Core.
      This commit has been authored by
      
      * Richard Eisenberg
      * Krzysztof Gogolewski
      * Matthew Pickering
      * Arnaud Spiwack
      
      With contributions from:
      
      * Mark Barbone
      * Alexander Vershilov
      
      Updates haddock submodule.
      40fa237e
    • Ben Gamari's avatar
      base: Bump to 4.15.0.0 · 7faa4509
      Ben Gamari authored
      7faa4509
    • Sylvain Henry's avatar
      T16190: only measure bytes_allocated · 0639dc10
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      Just adding `{-# LANGUAGE BangPatterns #-}` makes the two other metrics
      fluctuate by 13%.
      0639dc10
  2. 14 Jun, 2020 3 commits
  3. 13 Jun, 2020 7 commits
    • Ryan Scott's avatar
      Use HsForAllTelescope to avoid inferred, visible foralls · a31218f7
      Ryan Scott authored and Ben Gamari's avatar Ben Gamari committed
      Currently, `HsForAllTy` permits the combination of `ForallVis` and
      `Inferred`, but you can't actually typecheck code that uses it
      (e.g., `forall {a} ->`). This patch refactors `HsForAllTy` to use a
      new `HsForAllTelescope` data type that makes a type-level distinction
      between visible and invisible `forall`s such that visible `forall`s
      do not track `Specificity`. That part of the patch is actually quite
      small; the rest is simply changing consumers of `HsType` to
      accommodate this new type.
      
      Fixes #18235. Bumps the `haddock` submodule.
      a31218f7
    • Ben Gamari's avatar
      testsuite: Increase size of T12150 · 220c2d34
      Ben Gamari authored and  Marge Bot's avatar Marge Bot committed
      As noted in #18319, this test was previously very fragile. Increase its
      size to make it more likely that its fails with its newly-increased
      acceptance threshold.
      
      Metric Increase:
          T12150
      220c2d34
    • Oleg Grenrus's avatar
      Fix #12073: Add MonadFix Q instance · 9f09b608
      Oleg Grenrus authored and  Marge Bot's avatar Marge Bot committed
      9f09b608
    • Simon Peyton Jones's avatar
      Trim the demand for recursive product types · 42953902
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      Ticket #18304 showed that we need to be very careful
      when exploring the demand (esp usage demand) on recursive
      product types.
      
      This patch solves the problem by trimming the demand on such types --
      in effect, a form of "widening".
      
      See the Note [Trimming a demand to a type] in DmdAnal, which explains
      how I did this by piggy-backing on an existing mechansim for trimming
      demands becuase of GADTs.  The significant payload of this patch is
      very small indeed:
      
      * Make GHC.Core.Opt.WorkWrap.Utils.typeShape use RecTcChecker to
        avoid looking through recursive types.
      
      But on the way
      
      * I found that ae_rec_tc was entirely inoperative and did nothing.
        So I removed it altogether from DmdAnal.
      
      * I moved some code around in DmdAnal and Demand.
        (There are no actual changes in dmdFix.)
      
      * I changed the API of DmsAnal.dmdAnalRhsLetDown to return
        a StrictSig rather than a decorated Id
      
      * I removed the dead function peelTsFuns from Demand
      
      Performance effects:
      
      Nofib: 0.0% changes.  Not surprising, because they don't
             use recursive products
      
      Perf tests
      
      T12227:
        1% increase in compiler allocation, becuase $cto gets w/w'd.
        It did not w/w before because it takes a deeply nested
        argument, so the worker gets too many args, so we abandon w/w
        altogether (see GHC.Core.Opt.WorkWrap.Utils.isWorkerSmallEnough)
      
        With this patch we trim the demands.  That is not strictly
        necessary (since these Generic type constructors are like
        tuples -- they can't cause a loop) but the net result is that
        we now w/w $cto which is fine.
      
      UniqLoop:
        16% decrease in /runtime/ allocation. The UniqSupply is a
        recursive product, so currently we abandon all strictness on
        'churn'.  With this patch 'churn' gets useful strictness, and
        we w/w it.  Hooray
      
      Metric Decrease:
          UniqLoop
      
      Metric Increase:
          T12227
      42953902
    • Sylvain Henry's avatar
      Don't return preload units when we set DyNFlags · bfd0a78c
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      Preload units can be retrieved in UnitState when needed (i.e. in GHCi)
      bfd0a78c
    • Sylvain Henry's avatar
      DynFlags: make listVisibleModuleNames take a UnitState · 36e1daf0
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      36e1daf0
    • Sylvain Henry's avatar
      Only test T16190 with the NCG · 3445b965
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      T16190 is meant to test a NCG feature. It has already caused spurious
      failures in other MRs (e.g. !2165) when LLVM is used.
      3445b965
  4. 10 Jun, 2020 6 commits
    • Sylvain Henry's avatar
      test: fix conc038 · 8d07c48c
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      We had spurious failures of conc038 test on CI with stdout:
      
      ```
       newThread started
      -mainThread
      -Haskell: 2
       newThread back again
      +mainThread
       1 sec later
      
       shutting down
      +Haskell: 2
      ```
      8d07c48c
    • Roland Senn's avatar
      Initialize the allocation counter in GHCi to 0 (Fixes #16012) · 9b283e1b
      Roland Senn authored and  Marge Bot's avatar Marge Bot committed
      According to the documentation for the function `getAllocationCounter` in
      [System.Mem](http://hackage.haskell.org/package/base-4.14.0.0/docs/System-Mem.html)
      initialize the allocationCounter also in GHCi to 0.
      9b283e1b
    • Luke Lau's avatar
      Fix lookupGlobalOccRn_maybe sometimes reporting an error · 32fd37f5
      Luke Lau authored and  Marge Bot's avatar Marge Bot committed
      In some cases it was possible for lookupGlobalOccRn_maybe to return an
      error, when it should be returning a Nothing. If it called
      lookupExactOcc_either when there were no matching GlobalRdrElts in the
      otherwise case, it would return an error message. This could be caused
      when lookupThName_maybe in Template Haskell was looking in different
      namespaces (thRdrNameGuesses), guessing different namespaces that the
      name wasn't guaranteed to be found in.
      
      However, by addressing this some more accurate errors were being lost in
      the conversion to Maybes. So some of the lookup* functions have been
      shuffled about so that errors should always be ignored in
      lookup*_maybes, and propagated otherwise.
      
      This fixes #18263
      32fd37f5
    • Simon Peyton Jones's avatar
      Implement cast worker/wrapper properly · 6d49d5be
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      The cast worker/wrapper transformation transforms
         x = e |> co
      into
         y = e
         x = y |> co
      
      This is done by the simplifier, but we were being
      careless about transferring IdInfo from x to y,
      and about what to do if x is a NOINLNE function.
      This resulted in a series of bugs:
           #17673, #18093, #18078.
      
      This patch fixes all that:
      
      * Main change is in GHC.Core.Opt.Simplify, and
        the new prepareBinding function, which does this
        cast worker/wrapper transform.
        See Note [Cast worker/wrappers].
      
      * There is quite a bit of refactoring around
        prepareRhs, makeTrivial etc.  It's nicer now.
      
      * Some wrappers from strictness and cast w/w, notably those for
        a function with a NOINLINE, should inline very late. There
        wasn't really a mechanism for that, which was an existing bug
        really; so I invented a new finalPhase = Phase (-1).  It's used
        for all simplifier runs after the user-visible phase 2,1,0 have
        run.  (No new runs of the simplifier are introduced thereby.)
      
        See new Note [Compiler phases] in GHC.Types.Basic;
        the main changes are in GHC.Core.Opt.Driver
      
      * Doing this made me trip over two places where the AnonArgFlag on a
        FunTy was being lost so we could end up with (Num a -> ty)
        rather than (Num a => ty)
          - In coercionLKind/coercionRKind
          - In contHoleType in the Simplifier
      
        I fixed the former by defining mkFunctionType and using it in
        coercionLKind/RKind.
      
        I could have done the same for the latter, but the information
        is almost to hand.  So I fixed the latter by
          - adding sc_hole_ty to ApplyToVal (like ApplyToTy),
          - adding as_hole_ty to ValArg (like TyArg)
          - adding sc_fun_ty to StrictArg
        Turned out I could then remove ai_type from ArgInfo.  This is
        just moving the deck chairs around, but it worked out nicely.
      
        See the new Note [AnonArgFlag] in GHC.Types.Var
      
      * When looking at the 'arity decrease' thing (#18093) I discovered
        that stable unfoldings had a much lower arity than the actual
        optimised function.  That's what led to the arity-decrease
        message.  Simple solution: eta-expand.
      
        It's described in Note [Eta-expand stable unfoldings]
        in GHC.Core.Opt.Simplify
      
      * I also discovered that unsafeCoerce wasn't being inlined if
        the context was boring.  So (\x. f (unsafeCoerce x)) would
        create a thunk -- yikes!  I fixed that by making inlineBoringOK
        a bit cleverer: see Note [Inline unsafeCoerce] in GHC.Core.Unfold.
      
        I also found that unsafeCoerceName was unused, so I removed it.
      
      I made a test case for #18078, and a very similar one for #17673.
      
      The net effect of all this on nofib is very modest, but positive:
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
                 anna          -0.4%     -0.1%     -3.1%     -3.1%      0.0%
       fannkuch-redux          -0.4%     -0.3%     -0.1%     -0.1%      0.0%
             maillist          -0.4%     -0.1%     -7.8%     -1.0%    -14.3%
            primetest          -0.4%    -15.6%     -7.1%     -6.6%      0.0%
      --------------------------------------------------------------------------------
                  Min          -0.9%    -15.6%    -13.3%    -14.2%    -14.3%
                  Max          -0.3%      0.0%    +12.1%    +12.4%      0.0%
       Geometric Mean          -0.4%     -0.2%     -2.3%     -2.2%     -0.1%
      
      All following metric decreases are compile-time allocation decreases
      between -1% and -3%:
      
      Metric Decrease:
        T5631
        T13701
        T14697
        T15164
      6d49d5be
    • Ömer Sinan Ağacan's avatar
      Cross-module LambdaFormInfo passing · 7a737e89
      Ömer Sinan Ağacan authored and  Marge Bot's avatar Marge Bot committed
      
      
      - Store LambdaFormInfos of exported Ids in interface files
      - Use them in importing modules
      
      This is for optimization purposes: if we know LambdaFormInfo of imported
      Ids we can generate more efficient calling code, see `getCallMethod`.
      
      Exporting (putting them in interface files or in ModDetails) and
      importing (reading them from interface files) are both optional. We
      don't assume known LambdaFormInfos anywhere and do not change how we
      call Ids with unknown LambdaFormInfos.
      
      Runtime, allocation, and residency numbers when building
      Cabal-the-library (commit 0d4ee7ba3):
      
      (Log and .hp files are in the MR: !2842)
      
      |     | GHC HEAD | This patch | Diff           |
      |-----|----------|------------|----------------|
      | -O0 |  0:35.89 |    0:34.10 | -1.78s, -4.98% |
      | -O1 |  2:24.01 |    2:23.62 | -0.39s, -0.27% |
      | -O2 |  2:52.23 |    2:51.35 | -0.88s, -0.51% |
      
      |     | GHC HEAD        | This patch      | Diff                       |
      |-----|-----------------|-----------------|----------------------------|
      | -O0 |  54,843,608,416 |  54,878,769,544 |  +35,161,128 bytes, +0.06% |
      | -O1 | 227,136,076,400 | 227,569,045,168 | +432,968,768 bytes, +0.19% |
      | -O2 | 266,147,063,296 | 266,749,643,440 | +602,580,144 bytes, +0.22% |
      
      NOTE: Residency is measured with extra runtime args: `-i0 -h` which effectively
      turn all GCs into major GCs, and do GC more often.
      
      |     | GHC HEAD                   | This patch                   | Diff                       |
      |-----|----------------------------|------------------------------|----------------------------|
      | -O0 | 410,284,000 (910 samples)  | 411,745,008 (906 samples)    | +1,461,008 bytes, +0.35%   |
      | -O1 | 928,580,856 (2109 samples) | 943,506,552 (2103 samples)   | +14,925,696 bytes, +1.60%  |
      | -O2 | 993,951,352 (2549 samples) | 1,010,156,328 (2545 samples) | +16,204,9760 bytes, +1.63% |
      
      NoFib results:
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs    Instrs     Reads    Writes
      --------------------------------------------------------------------------------
                   CS           0.0%      0.0%     +0.0%     +0.0%     +0.0%
                  CSD           0.0%      0.0%      0.0%     +0.0%     +0.0%
                   FS           0.0%      0.0%     +0.0%     +0.0%     +0.0%
                    S           0.0%      0.0%     +0.0%     +0.0%     +0.0%
                   VS           0.0%      0.0%     +0.0%     +0.0%     +0.0%
                  VSD           0.0%      0.0%     +0.0%     +0.0%     +0.1%
                  VSM           0.0%      0.0%     +0.0%     +0.0%     +0.0%
                 anna           0.0%      0.0%     -0.3%     -0.8%     -0.0%
                 ansi           0.0%      0.0%     -0.0%     -0.0%      0.0%
                 atom           0.0%      0.0%     -0.0%     -0.0%      0.0%
               awards           0.0%      0.0%     -0.1%     -0.3%      0.0%
               banner           0.0%      0.0%     -0.0%     -0.0%     -0.0%
           bernouilli           0.0%      0.0%     -0.0%     -0.0%     -0.0%
         binary-trees           0.0%      0.0%     -0.0%     -0.0%     +0.0%
                boyer           0.0%      0.0%     -0.0%     -0.0%      0.0%
               boyer2           0.0%      0.0%     -0.0%     -0.0%      0.0%
                 bspt           0.0%      0.0%     -0.0%     -0.2%      0.0%
            cacheprof           0.0%      0.0%     -0.1%     -0.4%     +0.0%
             calendar           0.0%      0.0%     -0.0%     -0.0%      0.0%
             cichelli           0.0%      0.0%     -0.9%     -2.4%      0.0%
              circsim           0.0%      0.0%     -0.0%     -0.0%      0.0%
             clausify           0.0%      0.0%     -0.1%     -0.3%      0.0%
        comp_lab_zift           0.0%      0.0%     -0.0%     -0.0%     +0.0%
             compress           0.0%      0.0%     -0.0%     -0.0%     -0.0%
            compress2           0.0%      0.0%     -0.0%     -0.0%      0.0%
          constraints           0.0%      0.0%     -0.1%     -0.2%     -0.0%
         cryptarithm1           0.0%      0.0%     -0.0%     -0.0%      0.0%
         cryptarithm2           0.0%      0.0%     -1.4%     -4.1%     -0.0%
                  cse           0.0%      0.0%     -0.0%     -0.0%     -0.0%
         digits-of-e1           0.0%      0.0%     -0.0%     -0.0%     -0.0%
         digits-of-e2           0.0%      0.0%     -0.0%     -0.0%     -0.0%
               dom-lt           0.0%      0.0%     -0.1%     -0.2%      0.0%
                eliza           0.0%      0.0%     -0.5%     -1.5%      0.0%
                event           0.0%      0.0%     -0.0%     -0.0%     -0.0%
          exact-reals           0.0%      0.0%     -0.1%     -0.3%     +0.0%
               exp3_8           0.0%      0.0%     -0.0%     -0.0%     -0.0%
               expert           0.0%      0.0%     -0.3%     -1.0%     -0.0%
       fannkuch-redux           0.0%      0.0%     +0.0%     +0.0%     +0.0%
                fasta           0.0%      0.0%     -0.0%     -0.0%     +0.0%
                  fem           0.0%      0.0%     -0.0%     -0.0%      0.0%
                  fft           0.0%      0.0%     -0.0%     -0.0%      0.0%
                 fft2           0.0%      0.0%     -0.0%     -0.0%      0.0%
             fibheaps           0.0%      0.0%     -0.0%     -0.0%     +0.0%
                 fish           0.0%      0.0%      0.0%     -0.0%     +0.0%
                fluid           0.0%      0.0%     -0.4%     -1.2%     +0.0%
               fulsom           0.0%      0.0%     -0.0%     -0.0%      0.0%
               gamteb           0.0%      0.0%     -0.1%     -0.3%      0.0%
                  gcd           0.0%      0.0%     -0.0%     -0.0%      0.0%
          gen_regexps           0.0%      0.0%     -0.0%     -0.0%     -0.0%
               genfft           0.0%      0.0%     -0.0%     -0.0%      0.0%
                   gg           0.0%      0.0%     -0.0%     -0.0%     +0.0%
                 grep           0.0%      0.0%     -0.0%     -0.0%     -0.0%
               hidden           0.0%      0.0%     -0.1%     -0.4%     -0.0%
                  hpg           0.0%      0.0%     -0.2%     -0.5%     +0.0%
                  ida           0.0%      0.0%     -0.0%     -0.0%     +0.0%
                infer           0.0%      0.0%     -0.3%     -0.8%     -0.0%
              integer           0.0%      0.0%     -0.0%     -0.0%     +0.0%
            integrate           0.0%      0.0%     -0.0%     -0.0%      0.0%
         k-nucleotide           0.0%      0.0%     -0.0%     -0.0%     +0.0%
                kahan           0.0%      0.0%     -0.0%     -0.0%     +0.0%
              knights           0.0%      0.0%     -2.2%     -5.4%      0.0%
               lambda           0.0%      0.0%     -0.6%     -1.8%      0.0%
           last-piece           0.0%      0.0%     -0.0%     -0.0%      0.0%
                 lcss           0.0%      0.0%     -0.0%     -0.1%      0.0%
                 life           0.0%      0.0%     -0.0%     -0.1%      0.0%
                 lift           0.0%      0.0%     -0.2%     -0.6%     +0.0%
               linear           0.0%      0.0%     -0.0%     -0.0%     -0.0%
            listcompr           0.0%      0.0%     -0.0%     -0.0%      0.0%
             listcopy           0.0%      0.0%     -0.0%     -0.0%      0.0%
             maillist           0.0%      0.0%     -0.1%     -0.3%     +0.0%
               mandel           0.0%      0.0%     -0.0%     -0.0%      0.0%
              mandel2           0.0%      0.0%     -0.0%     -0.0%     -0.0%
                 mate          +0.0%      0.0%     -0.0%     -0.0%     -0.0%
              minimax           0.0%      0.0%     -0.2%     -1.0%      0.0%
              mkhprog           0.0%      0.0%     -0.1%     -0.2%     -0.0%
           multiplier           0.0%      0.0%     -0.0%     -0.0%     -0.0%
               n-body           0.0%      0.0%     -0.0%     -0.0%     +0.0%
             nucleic2           0.0%      0.0%     -0.1%     -0.2%      0.0%
                 para           0.0%      0.0%     -0.0%     -0.0%     -0.0%
            paraffins           0.0%      0.0%     -0.0%     -0.0%      0.0%
               parser           0.0%      0.0%     -0.2%     -0.7%      0.0%
              parstof           0.0%      0.0%     -0.0%     -0.0%     +0.0%
                  pic           0.0%      0.0%     -0.0%     -0.0%      0.0%
             pidigits           0.0%      0.0%     +0.0%     +0.0%     +0.0%
                power           0.0%      0.0%     -0.2%     -0.6%     +0.0%
               pretty           0.0%      0.0%     -0.0%     -0.0%     -0.0%
               primes           0.0%      0.0%     -0.0%     -0.0%      0.0%
            primetest           0.0%      0.0%     -0.0%     -0.0%     -0.0%
               prolog           0.0%      0.0%     -0.3%     -1.1%      0.0%
               puzzle           0.0%      0.0%     -0.0%     -0.0%      0.0%
               queens           0.0%      0.0%     -0.0%     -0.0%     +0.0%
              reptile           0.0%      0.0%     -0.0%     -0.0%      0.0%
      reverse-complem           0.0%      0.0%     -0.0%     -0.0%     +0.0%
              rewrite           0.0%      0.0%     -0.7%     -2.5%     -0.0%
                 rfib           0.0%      0.0%     -0.0%     -0.0%      0.0%
                  rsa           0.0%      0.0%     -0.0%     -0.0%      0.0%
                  scc           0.0%      0.0%     -0.1%     -0.2%     -0.0%
                sched           0.0%      0.0%     -0.0%     -0.0%     -0.0%
                  scs           0.0%      0.0%     -1.0%     -2.6%     +0.0%
               simple           0.0%      0.0%     +0.0%     -0.0%     +0.0%
                solid           0.0%      0.0%     -0.0%     -0.0%      0.0%
              sorting           0.0%      0.0%     -0.6%     -1.6%      0.0%
        spectral-norm           0.0%      0.0%     +0.0%      0.0%     +0.0%
               sphere           0.0%      0.0%     -0.0%     -0.0%     -0.0%
               symalg           0.0%      0.0%     -0.0%     -0.0%     +0.0%
                  tak           0.0%      0.0%     -0.0%     -0.0%      0.0%
            transform           0.0%      0.0%     -0.0%     -0.0%      0.0%
             treejoin           0.0%      0.0%     -0.0%     -0.0%      0.0%
            typecheck           0.0%      0.0%     -0.0%     -0.0%     +0.0%
              veritas          +0.0%      0.0%     -0.2%     -0.4%     +0.0%
                 wang           0.0%      0.0%     -0.0%     -0.0%      0.0%
            wave4main           0.0%      0.0%     -0.0%     -0.0%     -0.0%
         wheel-sieve1           0.0%      0.0%     -0.0%     -0.0%     -0.0%
         wheel-sieve2           0.0%      0.0%     -0.0%     -0.0%     +0.0%
                 x2n1           0.0%      0.0%     -0.0%     -0.0%     -0.0%
      --------------------------------------------------------------------------------
                  Min           0.0%      0.0%     -2.2%     -5.4%     -0.0%
                  Max          +0.0%      0.0%     +0.0%     +0.0%     +0.1%
       Geometric Mean          -0.0%     -0.0%     -0.1%     -0.3%     +0.0%
      
      Metric increases micro benchmarks tracked in #17686:
      
      Metric Increase:
          T12150
          T12234
          T12425
          T13035
          T5837
          T6048
          T9233
      Co-authored-by: Andreas Klebinger's avatarAndreas Klebinger <klebinger.andreas@gmx.at>
      7a737e89
    • Ryan Scott's avatar
      Always use rnImplicitBndrs to bring implicit tyvars into scope · a47e6442
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      This implements a first step towards #16762 by changing the renamer
      to always use `rnImplicitBndrs` to bring implicitly bound type
      variables into scope. The main change is in `rnFamInstEqn` and
      `bindHsQTyVars`, which previously used _ad hoc_ methods of binding
      their implicit tyvars.
      
      There are a number of knock-on consequences:
      
      * One of the reasons that `rnFamInstEqn` used an _ad hoc_ binding
        mechanism was to give more precise source locations in
        `-Wunused-type-patterns` warnings. (See
        ghc/ghc#16762 (comment 273343) for an
        example of this.) However, these warnings are actually a little
        _too_ precise, since implicitly bound type variables don't have
        exact binding sites like explicitly bound type variables do.
        A similar problem existed for
        "`Different names for the same type variable`" errors involving
        implicit tyvars bound by `bindHsQTyVars`.
        Therefore, we simply accept the less precise (but more accurate)
        source locations from `rnImplicitBndrs` in `rnFamInstEqn` and
        `bindHsQTyVars`. See
        `Note [Source locations for implicitly bound type variables]` in
        `GHC.Rename.HsType` for the full story.
      * In order for `rnImplicitBndrs` to work in `rnFamInstEqn`, it needs
        to be able to look up names from the parent class (in the event
        that we are renaming an associated type family instance). As a
        result, `rnImplicitBndrs` now takes an argument of type
        `Maybe assoc`, which is `Just` in the event that a type family
        instance is associated with a class.
      * Previously, GHC kept track of three type synonyms for free type
        variables in the renamer: `FreeKiTyVars`, `FreeKiTyVarsDups`
        (which are allowed to contain duplicates), and
        `FreeKiTyVarsNoDups` (which contain no duplicates). However, making
        is a distinction between `-Dups` and `-NoDups` is now pointless, as
        all code that returns `FreeKiTyVars{,Dups,NoDups}` will eventually
        end up being passed to `rnImplicitBndrs`, which removes duplicates.
        As a result, I decided to just get rid of `FreeKiTyVarsDups` and
        `FreeKiTyVarsNoDups`, leaving only `FreeKiTyVars`.
      * The `bindLRdrNames` and `deleteBys` functions are now dead code, so
        I took the liberty of removing them.
      a47e6442
  5. 09 Jun, 2020 1 commit
    • Ryan Scott's avatar
      Make GADT constructors adhere to the forall-or-nothing rule properly · 72c7fe9a
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      Issue #18191 revealed that the types of GADT constructors don't quite
      adhere to the `forall`-or-nothing rule. This patch serves to clean up
      this sad state of affairs somewhat. The main change is not in the
      code itself, but in the documentation, as this patch introduces two
      sections to the GHC User's Guide:
      
      * A "Formal syntax for GADTs" section that presents a BNF-style
        grammar for what is and isn't allowed in GADT constructor types.
        This mostly exists to codify GHC's existing behavior, but it also
        imposes a new restriction that addresses #18191: the outermost
        `forall` and/or context in a GADT constructor is not allowed to be
        surrounded by parentheses. Doing so would make these
        `forall`s/contexts nested, and GADTs do not support nested
        `forall`s/contexts at present.
      
      * A "`forall`-or-nothing rule" section that describes exactly what
        the `forall`-or-nothing rule is all about. Surprisingly, there was
        no mention of this anywhere in the User's Guide up until now!
      
      To adhere the new specification in the "Formal syntax for GADTs"
      section of the User's Guide, the following code changes were made:
      
      * A new function, `GHC.Hs.Type.splitLHsGADTPrefixTy`, was introduced.
        This is very much like `splitLHsSigmaTy`, except that it avoids
        splitting apart any parentheses, which can be syntactically
        significant for GADT types. See
        `Note [No nested foralls or contexts in GADT constructors]` in
        `GHC.Hs.Type`.
      
      * `ConDeclGADTPrefixPs`, an extension constructor for `XConDecl`, was
        introduced so that `GHC.Parser.PostProcess.mkGadtDecl` can return
        it when given a prefix GADT constructor. Unlike `ConDeclGADT`,
        `ConDeclGADTPrefixPs` does not split the GADT type into its argument
        and result types, as this cannot be done until after the type is
        renamed (see `Note [GADT abstract syntax]` in `GHC.Hs.Decls` for why
        this is the case).
      
      * `GHC.Renamer.Module.rnConDecl` now has an additional case for
        `ConDeclGADTPrefixPs` that (1) splits apart the full `LHsType` into
        its `forall`s, context, argument types, and result type, and
        (2) checks for nested `forall`s/contexts. Step (2) used to be
        performed the typechecker (in `GHC.Tc.TyCl.badDataConTyCon`) rather
        than the renamer, but now the relevant code from the typechecker
        can simply be deleted.
      
        One nice side effect of this change is that we are able to give a
        more accurate error message for GADT constructors that use visible
        dependent quantification (e.g., `MkFoo :: forall a -> a -> Foo a`),
        which improves the stderr in the `T16326_Fail6` test case.
      
      Fixes #18191. Bumps the Haddock submodule.
      72c7fe9a
  6. 05 Jun, 2020 2 commits
    • Ryan Scott's avatar
      Simplify bindLHsTyVarBndrs and bindHsQTyVars · 2dff8141
      Ryan Scott authored
      Both `bindLHsTyVarBndrs` and `bindHsQTyVars` take two separate
      `Maybe` arguments, which I find terribly confusing. Thankfully, it's
      possible to remove one `Maybe` argument from each of these functions,
      which this patch accomplishes:
      
      * `bindHsQTyVars` takes a `Maybe SDoc` argument, which is `Just` if
        GHC should warn about any of the quantified type variables going
        unused. However, every call site uses `Nothing` in practice. This
        makes sense, since it doesn't really make sense to warn about
        unused type variables bound by an `LHsQTyVars`. For instance, you
        wouldn't warn about the `a` in `data Proxy a = Proxy` going unused.
      
        As a result, I simply remove this `Maybe SDoc` argument altogether.
      * `bindLHsTyVarBndrs` also takes a `Maybe SDoc` argument for the same
        reasons that `bindHsQTyVars` took one. To make things more
        confusing, however, `bindLHsTyVarBndrs` also takes a separate
        `HsDocContext` argument, which is pretty-printed (to an `SDoc`) in
        warnings and error messages.
      
        In practice, the `Maybe SDoc` and the `HsDocContext` often contain
        the same text. See the call sites for `bindLHsTyVarBndrs` in
        `rnFamInstEqn` and `rnConDecl`, for instance. There are only a
        handful of call sites where the text differs between the
        `Maybe SDoc` and `HsDocContext` arguments:
      
        * In `rnHsRuleDecl`, where the `Maybe SDoc` says "`In the rule`"
          and the `HsDocContext` says "`In the transformation rule`".
        * In `rnHsTyKi`/`rn_ty`, where the `Maybe SDoc` says
          "`In the type`" but the `HsDocContext` is inhereted from the
          surrounding context (e.g., if `rnHsTyKi` were called on a
          top-level type signature, the `HsDocContext` would be
          "`In the type signature`" instead)
      
        In both cases, warnings/error messages arguably _improve_ by
        unifying making the `Maybe SDoc`'s text match that of the
        `HsDocContext`. As a result, I decided to remove the `Maybe SDoc`
        argument to `bindLHsTyVarBndrs` entirely and simply reuse the text
        from the `HsDocContext`. (I decided to change the phrase
        "transformation rule" to "rewrite rule" while I was in the area.)
      
        The `Maybe SDoc` argument has one other purpose: signaling when to
        emit "`Unused quantified type variable`" warnings. To recover this
        functionality, I replaced the `Maybe SDoc` argument with a
        boolean-like `WarnUnusedForalls` argument. The only
        `bindLHsTyVarBndrs` call site that chooses _not_ to emit these
        warnings in `bindHsQTyVars`.
      2dff8141
    • Simon Peyton Jones's avatar
      Simple subsumption · 2b792fac
      Simon Peyton Jones authored and Ben Gamari's avatar Ben Gamari committed
      This patch simplifies GHC to use simple subsumption.
        Ticket #17775
      
      Implements GHC proposal #287
         https://github.com/ghc-proposals/ghc-proposals/blob/master/
         proposals/0287-simplify-subsumption.rst
      
      All the motivation is described there; I will not repeat it here.
      The implementation payload:
       * tcSubType and friends become noticably simpler, because it no
         longer uses eta-expansion when checking subsumption.
       * No deeplyInstantiate or deeplySkolemise
      
      That in turn means that some tests fail, by design; they can all
      be fixed by eta expansion.  There is a list of such changes below.
      
      Implementing the patch led me into a variety of sticky corners, so
      the patch includes several othe changes, some quite significant:
      
      * I made String wired-in, so that
          "foo" :: String   rather than
          "foo" :: [Char]
        This improves error messages, and fixes #15679
      
      * The pattern match checker relies on knowing about in-scope equality
        constraints, andd adds them to the desugarer's environment using
        addTyCsDs.  But the co_fn in a FunBind was missed, and for some reason
        simple-subsumption ends up with dictionaries there. So I added a
        call to addTyCsDs.  This is really part of #18049.
      
      * I moved the ic_telescope field out of Implication and into
        ForAllSkol instead.  This is a nice win; just expresses the code
        much better.
      
      * There was a bug in GHC.Tc.TyCl.Instance.tcDataFamInstHeader.
        We called checkDataKindSig inside tc_kind_sig, /before/
        solveEqualities and zonking.  Obviously wrong, easily fixed.
      
      * solveLocalEqualitiesX: there was a whole mess in here, around
        failing fast enough.  I discovered a bad latent bug where we
        could successfully kind-check a type signature, and use it,
        but have unsolved constraints that could fill in coercion
        holes in that signature --  aargh.
      
        It's all explained in Note [Failure in local type signatures]
        in GHC.Tc.Solver. Much better now.
      
      * I fixed a serious bug in anonymous type holes. IN
          f :: Int -> (forall a. a -> _) -> Int
        that "_" should be a unification variable at the /outer/
        level; it cannot be instantiated to 'a'.  This was plain
        wrong.  New fields mode_lvl and mode_holes in TcTyMode,
        and auxiliary data type GHC.Tc.Gen.HsType.HoleMode.
      
        This fixes #16292, but makes no progress towards the more
        ambitious #16082
      
      * I got sucked into an enormous refactoring of the reporting of
        equality errors in GHC.Tc.Errors, especially in
            mkEqErr1
            mkTyVarEqErr
            misMatchMsg
            misMatchMsgOrCND
        In particular, the very tricky mkExpectedActualMsg function
        is gone.
      
        It took me a full day.  But the result is far easier to understand.
        (Still not easy!)  This led to various minor improvements in error
        output, and an enormous number of test-case error wibbles.
      
        One particular point: for occurs-check errors I now just say
           Can't match 'a' against '[a]'
        rather than using the intimidating language of "occurs check".
      
      * Pretty-printing AbsBinds
      
      Tests review
      
      * Eta expansions
         T11305: one eta expansion
         T12082: one eta expansion (undefined)
         T13585a: one eta expansion
         T3102:  one eta expansion
         T3692:  two eta expansions (tricky)
         T2239:  two eta expansions
         T16473: one eta
         determ004: two eta expansions (undefined)
         annfail06: two eta (undefined)
         T17923: four eta expansions (a strange program indeed!)
         tcrun035: one eta expansion
      
      * Ambiguity check at higher rank.  Now that we have simple
        subsumption, a type like
           f :: (forall a. Eq a => Int) -> Int
        is no longer ambiguous, because we could write
           g :: (forall a. Eq a => Int) -> Int
           g = f
        and it'd typecheck just fine.  But f's type is a bit
        suspicious, and we might want to consider making the
        ambiguity check do a check on each sub-term.  Meanwhile,
        these tests are accepted, whereas they were previously
        rejected as ambiguous:
           T7220a
           T15438
           T10503
           T9222
      
      * Some more interesting error message wibbles
         T13381: Fine: one error (Int ~ Exp Int)
                 rather than two (Int ~ Exp Int, Exp Int ~ Int)
         T9834:  Small change in error (improvement)
         T10619: Improved
         T2414:  Small change, due to order of unification, fine
         T2534:  A very simple case in which a change of unification order
                 means we get tow unsolved constraints instead of one
         tc211: bizarre impredicative tests; just accept this for now
      
      Updates Cabal and haddock submodules.
      
      Metric Increase:
        T12150
        T12234
        T5837
        haddock.base
      Metric Decrease:
        haddock.compiler
        haddock.Cabal
        haddock.base
      
      Merge note: This appears to break the
      `UnliftedNewtypesDifficultUnification` test. It has been marked as
      broken in the interest of merging.
      
      (cherry picked from commit 66b7b195)
      2b792fac
  7. 04 Jun, 2020 3 commits
    • Alex D's avatar
      Add test for #17669 · c330331a
      Alex D authored and  Marge Bot's avatar Marge Bot committed
      c330331a
    • Luke Lau's avatar
      Fix documentation on type families not being extracted · 2bd3929a
      Luke Lau authored and  Marge Bot's avatar Marge Bot committed
      It looks like the location of the Names used for CoAxioms on type
      families are now located at their type constructors. Previously, Docs.hs
      thought the Names were located in the RHS, so the RealSrcSpan in the
      instanceMap and getInstLoc didn't match up. Fixes #18241
      2bd3929a
    • John Ericson's avatar
      Clean up boot vs non-boot disambiguating types · 32a4ae90
      John Ericson authored and  Marge Bot's avatar Marge Bot committed
      We often have (ModuleName, Bool) or (Module, Bool) pairs for "extended"
      module names (without or with a unit id) disambiguating boot and normal
      modules. We think this is important enough across the compiler that it
      deserves a new nominal product type. We do this with synnoyms and a
      functor named with a `Gen` prefix, matching other newly created
      definitions.
      
      It was also requested that we keep custom `IsBoot` / `NotBoot` sum type.
      So we have it too. This means changing many the many bools to use that
      instead.
      
      Updates `haddock` submodule.
      32a4ae90
  8. 01 Jun, 2020 12 commits
  9. 29 May, 2020 1 commit
    • Ben Gamari's avatar
      Eta expand un-saturated primops · 277c2f26
      Ben Gamari authored and  Marge Bot's avatar Marge Bot committed
      Now since we no longer try to predict CAFfyness we have no need for the
      solution to #16846. Eta expanding unsaturated primop applications is
      conceptually simpler, especially in the presence of levity polymorphism.
      
      This essentially reverts cac8dc9f,
      as suggested in #18079.
      
      Closes #18079.
      277c2f26
  10. 28 May, 2020 1 commit
    • Sebastian Graf's avatar
      DmdAnal: Recognise precise exceptions from case alternatives (#18086) · 08dab5f7
      Sebastian Graf authored and  Marge Bot's avatar Marge Bot committed
      Consider
      
      ```hs
      m :: IO ()
      m = do
        putStrLn "foo"
        error "bar"
      ```
      
      `m` (from #18086) always throws a (precise or imprecise) exception or
      diverges. Yet demand analysis infers `<L,A>` as demand signature instead
      of `<L,A>x` for it.
      
      That's because the demand analyser sees `putStrLn` occuring in a case
      scrutinee and decides that it has to `deferAfterPreciseException`,
      because `putStrLn` throws a precise exception on some control flow
      paths. This will mask the `botDiv` `Divergence`of the single case alt
      containing `error` to `topDiv`. Since `putStrLn` has `topDiv` itself,
      the final `Divergence` is `topDiv`.
      
      This is easily fixed: `deferAfterPreciseException` works by `lub`ing
      with the demand type of a virtual case branch denoting the precise
      exceptional control flow. We used `nopDmdType` before, but we can be
      more precise and use `exnDmdType`, which is `nopDmdType` with `exnDiv`.
      
      Now the `Divergence` from the case alt will degrade `botDiv` to `exnDiv`
      instead of `topDiv`, which combines with the result from the scrutinee
      to `exnDiv`, and all is well.
      
      Fixes #18086.
      08dab5f7