1. 13 Jun, 2020 20 commits
  2. 11 Jun, 2020 1 commit
  3. 10 Jun, 2020 12 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
      -Haskell: 2
       newThread back again
       1 sec later
       shutting down
      +Haskell: 2
    • 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
      initialize the allocationCounter also in GHCi to 0.
    • 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
    • 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
         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
        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:
    • Simon Peyton Jones's avatar
      Optimisation in Unique.Supply · 9454511b
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      This patch switches on -fno-state-hack in GHC.Types.Unique.Supply.
      It turned out that my fixes for #18078 (coercion floating) changed the
      optimisation pathway for mkSplitUniqSupply in such a way that we had
      an extra allocation inside the inner loop.  Adding -fno-state-hack
      fixed that -- and indeed the loop in mkSplitUniqSupply is a classic
      example of the way in which -fno-state-hack can be bad; see #18238.
      Moreover, the new code is better than the old.  They allocate
      the same, but the old code ends up with a partial application.
      The net effect is that the test
      runs 20% faster!   From 2.5s down to 2.0s.  The allocation numbers
      are the same -- but elapsed time falls. Good!
      The bad thing about this is that it's terribly delicate.  But
      at least it's a good example of such delicacy in action.
      There is a long Note [Optimising the unique supply] which now
      explains all this.
    • Shayne Fletcher's avatar
      Give Language a Bounded instance · 3b22b14a
      Shayne Fletcher authored and  Marge Bot's avatar Marge Bot committed
    • Ö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                       |
    • Shayne Fletcher's avatar
      Expose impliedGFlags, impledOffGFlags, impliedXFlags · ccd6843d
      Shayne Fletcher authored and  Marge Bot's avatar Marge Bot committed
    • Ömer Sinan Ağacan's avatar
      Fix -fkeep-cafs flag name in users guide · 87102928
      Ömer Sinan Ağacan authored and  Marge Bot's avatar Marge Bot committed
    • Ömer Sinan Ağacan's avatar
      rts: Remove unused GET_ENTRY closure macro · 92de9e25
      Ömer Sinan Ağacan authored and  Marge Bot's avatar Marge Bot committed
      This macro is not used and got broken in the meantime, as ENTRY_CODE was
    • Takenobu Tani's avatar
      Clarify leaf module names for new module hierarchy · 24879129
      Takenobu Tani authored and  Marge Bot's avatar Marge Bot committed
      This updates comments only.
      This patch replaces leaf module names according to new module
      hierarchy [1][2] as followings:
      * Expand leaf names to easily find the module path:
        for instance, `Id.hs` to `GHC.Types.Id`.
      * Modify leaf names according to new module hierarchy:
        for instance, `Convert.hs` to `GHC.ThToHs`.
      * Fix typo:
        for instance, `GHC.Core.TyCo.Rep.hs` to `GHC.Core.TyCo.Rep`
      See also !3375
      [1]: https://gitlab.haskell.org/ghc/ghc/-/wikis/Make-GHC-codebase-more-modular
      [2]: ghc/ghc#13009
    • 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.
  4. 09 Jun, 2020 2 commits
    • 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
      * `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.
    • Takenobu Tani's avatar
      Add link to GHC's wiki in the GHC API header · 9b607671
      Takenobu Tani authored and  Marge Bot's avatar Marge Bot committed
      This adds a URL to point to GHC's wiki in the GHC API header.
      Newcomers could easily find more information from the GHC API's
      web like [1].
      [1]: Current version, https://ghc.gitlab.haskell.org/ghc/doc/libraries/ghc-
      [skip ci]
  5. 07 Jun, 2020 5 commits