1. 18 Feb, 2021 1 commit
  2. 06 Feb, 2021 2 commits
    • Brian Wignall's avatar
      Fix typos · 3da472f0
      Brian Wignall authored
    • Danya Rogozin's avatar
      The Char kind (#11342) · 7f3524ef
      Danya Rogozin authored
      Co-authored-by: Rinat Striungis's avatarRinat Stryungis <rinat.stryungis@serokell.io>
      Implement GHC Proposal #387
      * Parse char literals 'x' at the type level
      * New built-in type families CmpChar, ConsSymbol, UnconsSymbol
      * New KnownChar class (cf. KnownSymbol and KnownNat)
      * New SomeChar type (cf. SomeSymbol and SomeNat)
      * CharTyLit support in template-haskell
      Updated submodules: binary, haddock.
      Metric Decrease:
      Metric Increase:
  3. 24 Dec, 2020 1 commit
    • Simon Peyton Jones's avatar
      Clone the binders of a SAKS where necessary · e7d8e4ee
      Simon Peyton Jones authored
      Given a kind signature
         type T :: forall k. k -> forall k. k -> blah
         data T a b = ...
      where those k's have the same unique (which is possible;
      see #19093) we were giving the tyConBinders in tycon T the same
      unique, which caused chaos.
      Fix is simple: ensure uniqueness when decomposing the kind signature.
      See GHC.Tc.Gen.HsType.zipBinders
  4. 15 Dec, 2020 1 commit
  5. 14 Dec, 2020 4 commits
    • Andrew Martin's avatar
      Implement BoxedRep proposal · 6c2eb223
      Andrew Martin authored
      This implements the BoxedRep proposal, refacoring the `RuntimeRep`
      hierarchy from:
      data RuntimeRep = LiftedPtrRep | UnliftedPtrRep | ...
      data RuntimeRep = BoxedRep Levity | ...
      data Levity = Lifted | Unlifted
      Closes #17526.
    • Ben Gamari's avatar
      Optimise nullary type constructor usage · dad87210
      Ben Gamari authored
      During the compilation of programs GHC very frequently deals with
      the `Type` type, which is a synonym of `TYPE 'LiftedRep`. This patch
      teaches GHC to avoid expanding the `Type` synonym (and other nullary
      type synonyms) during type comparisons, saving a good amount of work.
      This optimisation is described in `Note [Comparing nullary type
      To maximize the impact of this optimisation, we introduce a few
      special-cases to reduce `TYPE 'LiftedRep` to `Type`. See
      `Note [Prefer Type over TYPE 'LiftedPtrRep]`.
      Closes #17958.
      Metric Decrease:
    • Ben Gamari's avatar
      Revert "Optimise nullary type constructor usage" · 92377c27
      Ben Gamari authored
      This was inadvertently merged.
      This reverts commit 7e9debd4.
    • Ben Gamari's avatar
      Optimise nullary type constructor usage · 7e9debd4
      Ben Gamari authored
      During the compilation of programs GHC very frequently deals with
      the `Type` type, which is a synonym of `TYPE 'LiftedRep`. This patch
      teaches GHC to avoid expanding the `Type` synonym (and other nullary
      type synonyms) during type comparisons, saving a good amount of work.
      This optimisation is described in `Note [Comparing nullary type
      To maximize the impact of this optimisation, we introduce a few
      special-cases to reduce `TYPE 'LiftedRep` to `Type`. See
      `Note [Prefer Type over TYPE 'LiftedPtrRep]`.
      Closes #17958.
      Metric Decrease:
  6. 02 Dec, 2020 1 commit
    • Richard Eisenberg's avatar
      Remove flattening variables · 8bb52d91
      Richard Eisenberg authored
      This patch redesigns the flattener to simplify type family applications
      directly instead of using flattening meta-variables and skolems. The key new
      innovation is the CanEqLHS type and the new CEqCan constraint (Ct). A CanEqLHS
      is either a type variable or exactly-saturated type family application; either
      can now be rewritten using a CEqCan constraint in the inert set.
      Because the flattener no longer reduces all type family applications to
      variables, there was some performance degradation if a lengthy type family
      application is now flattened over and over (not making progress). To
      compensate, this patch contains some extra optimizations in the flattener,
      leading to a number of performance improvements.
      Close #18875.
      Close #18910.
      There are many extra parts of the compiler that had to be affected in writing
      this patch:
      * The family-application cache (formerly the flat-cache) sometimes stores
        coercions built from Given inerts. When these inerts get kicked out, we must
        kick out from the cache as well. (This was, I believe, true previously, but
        somehow never caused trouble.) Kicking out from the cache requires adding a
        filterTM function to TrieMap.
      * This patch obviates the need to distinguish "blocking" coercion holes from
        non-blocking ones (which, previously, arose from CFunEqCans). There is thus
        some simplification around coercion holes.
      * Extra commentary throughout parts of the code I read through, to preserve
        the knowledge I gained while working.
      * A change in the pure unifier around unifying skolems with other types.
        Unifying a skolem now leads to SurelyApart, not MaybeApart, as documented
        in Note [Binding when looking up instances] in GHC.Core.InstEnv.
      * Some more use of MCoercion where appropriate.
      * Previously, class-instance lookup automatically noticed that e.g. C Int was
        a "unifier" to a target [W] C (F Bool), because the F Bool was flattened to
        a variable. Now, a little more care must be taken around checking for
        unifying instances.
      * Previously, tcSplitTyConApp_maybe would split (Eq a => a). This is silly,
        because (=>) is not a tycon in Haskell. Fixed now, but there are some
        knock-on changes in e.g. TrieMap code and in the canonicaliser.
      * New function anyFreeVarsOf{Type,Co} to check whether a free variable
        satisfies a certain predicate.
      * Type synonyms now remember whether or not they are "forgetful"; a forgetful
        synonym drops at least one argument. This is useful when flattening; see
      * The pattern-match completeness checker invokes the solver. This invocation
        might need to look through newtypes when checking representational equality.
        Thus, the desugarer needs to keep track of the in-scope variables to know
        what newtype constructors are in scope. I bet this bug was around before but
        never noticed.
      * Extra-constraints wildcards are no longer simplified before printing.
        See Note [Do not simplify ConstraintHoles] in GHC.Tc.Solver.
      * Whether or not there are Given equalities has become slightly subtler.
        See the new HasGivenEqs datatype.
      * Note [Type variable cycles in Givens] in GHC.Tc.Solver.Canonical
        explains a significant new wrinkle in the new approach.
      * See Note [What might match later?] in GHC.Tc.Solver.Interact, which
        explains the fix to #18910.
      * The inert_count field of InertCans wasn't actually used, so I removed
      Though I (Richard) did the implementation, Simon PJ was very involved
      in design and review.
      This updates the Haddock submodule to avoid #18932 by adding
      a type signature.
      Metric Decrease:
      Metric Increase:
  7. 15 Nov, 2020 2 commits
    • Ryan Scott's avatar
      Use tcSplitForAllInvisTyVars (not tcSplitForAllTyVars) in more places · 645444af
      Ryan Scott authored
      The use of `tcSplitForAllTyVars` in `tcDataFamInstHeader` was the immediate
      cause of #18939, and replacing it with a new `tcSplitForAllInvisTyVars`
      function (which behaves like `tcSplitForAllTyVars` but only splits invisible
      type variables) fixes the issue. However, this led me to realize that _most_
      uses of `tcSplitForAllTyVars` in GHC really ought to be
      `tcSplitForAllInvisTyVars` instead. While I was in town, I opted to replace
      most uses of `tcSplitForAllTys` with `tcSplitForAllTysInvis` to reduce the
      likelihood of such bugs in the future.
      I say "most uses" above since there is one notable place where we _do_ want
      to use `tcSplitForAllTyVars`: in `GHC.Tc.Validity.forAllTyErr`, which produces
      the "`Illegal polymorphic type`" error message if you try to use a higher-rank
      `forall` without having `RankNTypes` enabled. Here, we really do want to split
      all `forall`s, not just invisible ones, or we run the risk of giving an
      inaccurate error message in the newly added `T18939_Fail` test case.
      I debated at some length whether I wanted to name the new function
      `tcSplitForAllInvisTyVars` or `tcSplitForAllTyVarsInvisible`, but in the end,
      I decided that I liked the former better. For consistency's sake, I opted to
      rename the existing `splitPiTysInvisible` and `splitPiTysInvisibleN` functions
      to `splitInvisPiTys` and `splitPiTysInvisN`, respectively, so that they use the
      same naming convention. As a consequence, this ended up requiring a `haddock`
      submodule bump.
      Fixes #18939.
    • Ryan Scott's avatar
      Name (tc)SplitForAll- functions more consistently · d61adb3d
      Ryan Scott authored
      There is a zoo of `splitForAll-` functions in `GHC.Core.Type` (as well as
      `tcSplitForAll-` functions in `GHC.Tc.Utils.TcType`) that all do very similar
      things, but vary in the particular form of type variable that they return. To
      make things worse, the names of these functions are often quite misleading.
      Some particularly egregious examples:
      * `splitForAllTys` returns `TyCoVar`s, but `splitSomeForAllTys` returns
      * `splitSomeForAllTys` returns `VarBndr`s, but `tcSplitSomeForAllTys` returns
      * `splitForAllTys` returns `TyCoVar`s, but `splitForAllTysInvis` returns
        `InvisTVBinder`s. (This in particular arose in the context of #18939, and
        this finally motivated me to bite the bullet and improve the status quo
        vis-à-vis how we name these functions.)
      In an attempt to bring some sanity to how these functions are named, I have
      opted to rename most of these functions en masse to use consistent suffixes
      that describe the particular f...
  8. 31 Oct, 2020 1 commit
    • Ryan Scott's avatar
      Make typechecker equality consider visibility in ForAllTys · 57c3db96
      Ryan Scott authored
      Previously, `can_eq_nc'` would equate `ForAllTy`s regardless of their
      `ArgFlag`, including `forall i -> i -> Type` and `forall i. i -> Type`! To fix
      this, `can_eq_nc'` now uses the `sameVis` function to first check if the
      `ArgFlag`s are equal modulo specificity. I have also updated `tcEqType`'s
      implementation to match this behavior. For more explanation on the "modulo
      specificity" part, see the new `Note [ForAllTy and typechecker equality]`
      in `GHC.Tc.Solver.Canonical`.
      While I was in town, I fixed some related documentation issues:
      * I added `Note [Typechecker equality]` to `GHC.Tc.Utils.TcType` to describe
        what exactly distinguishes `can_eq_nc'` and `tcEqType` (which implement
        typechecker equality) from `eqType` (which implements definitional equality,
        which does not care about the `ArgFlags` of `ForAllTy`s at all).
      * The User's Guide had some outdated prose on the specified/inferred
        distinction being different for types and kinds, a holdover from #15079. This
        is no longer the case on today's GHC, so I removed this prose, added some new
        prose to take its place, and added a regression test for the programs in
      * The User's Guide had some _more_ outdated prose on inferred type variables
        not being allowed in `default` type signatures for class methods, which is no
        longer true as of the resolution of #18432.
      * The related `Note [Deferred Unification]` was being referenced as
        `Note [Deferred unification]` elsewhere, which made it harder to `grep`
        for. I decided to change the name of the Note to `Deferred unification`
        for consistency with the capitalization style used for most other Notes.
      Fixes #18863.
  9. 29 Oct, 2020 1 commit
    • Sylvain Henry's avatar
      Split GHC.Driver.Types · 0e9f6def
      Sylvain Henry authored
      I was working on making DynFlags stateless (#17957), especially by
      storing loaded plugins into HscEnv instead of DynFlags. It turned out to
      be complicated because HscEnv is in GHC.Driver.Types but LoadedPlugin
      isn't: it is in GHC.Driver.Plugins which depends on GHC.Driver.Types. I
      didn't feel like introducing yet another hs-boot file to break the loop.
      Additionally I remember that while we introduced the module hierarchy
      (#13009) we talked about splitting GHC.Driver.Types because it contained
      various unrelated types and functions, but we never executed. I didn't
      feel like making GHC.Driver.Types bigger with more unrelated Plugins
      related types, so finally I bit the bullet and split GHC.Driver.Types.
      As a consequence this patch moves a lot of things. I've tried to put
      them into appropriate modules but nothing is set in stone.
      Several other things moved to avoid loops.
      * Removed Binary instances from GHC.Utils.Binary for random compiler
      * Moved Typeable Binary instances into GHC.Utils.Binary.Typeable: they
        import a lot of things that users of GHC.Utils.Binary don't want to
        depend on.
      * put everything related to Units/Modules under GHC.Unit:
        GHC.Unit.Finder, GHC.Unit.Module.{ModGuts,ModIface,Deps,etc.}
      * Created several modules under GHC.Types: GHC.Types.Fixity, SourceText,
      * Split GHC.Utils.Error (into GHC.Types.Error)
      * Finally removed GHC.Driver.Types
      Note that this patch doesn't put loaded plugins into HscEnv. It's left
      for another patch.
      Bump haddock submodule
  10. 20 Oct, 2020 1 commit
    • Krzysztof Gogolewski's avatar
      Minor comments, update linear types docs · 6c7a5c0c
      Krzysztof Gogolewski authored
      - Update comments: placeHolderTypeTc no longer exists
        "another level check problem" was a temporary comment from linear types
      - Use Mult type synonym (reported in #18676)
      - Mention multiplicity-polymorphic fields in linear types docs
  11. 13 Oct, 2020 1 commit
    • Rinat Striungis's avatar
      Unification of Nat and Naturals · 8f4f5794
      Rinat Striungis authored
      This commit removes the separate kind 'Nat' and enables promotion
      of type 'Natural' for using as type literal.
      It partially solves #10776
      Now the following code will be successfully typechecked:
          data C = MkC Natural
          type CC = MkC 1
      Before this change we had to create the separate type for promotion
          data C = MkC Natural
          data CP = MkCP Nat
          type CC = MkCP 1
      But CP is uninhabited in terms.
      For backward compatibility type synonym `Nat` has been made:
          type Nat = Natural
      The user's documentation and tests have been updated.
      The haddock submodule also have been updated.
  12. 07 Oct, 2020 1 commit
    • Krzysztof Gogolewski's avatar
      Misc cleanup · e91ddddd
      Krzysztof Gogolewski authored
      * Include funTyCon in exposedPrimTyCons.
        Every single place using exposedPrimTyCons was adding funTyCon
      * Remove unused synTyConResKind and ieLWrappedName
      * Add recordSelectorTyCon_maybe
      * In exprType, panic instead of giving a trace message and dummy output.
        This prevents #18767 reoccurring.
      * Fix compilation error in fragile concprog001 test (part of #18732)
  13. 25 Aug, 2020 1 commit
  14. 12 Aug, 2020 1 commit
    • Sylvain Henry's avatar
      DynFlags: disentangle Outputable · accbc242
      Sylvain Henry authored
      - put panic related functions into GHC.Utils.Panic
      - put trace related functions using DynFlags in GHC.Driver.Ppr
      One step closer making Outputable fully independent of DynFlags.
      Bump haddock submodule
  15. 24 Jul, 2020 1 commit
    • Simon Peyton Jones's avatar
      Care with occCheckExpand in kind of occurrences · ba205046
      Simon Peyton Jones authored
      Issue #18451 showed that we could get an infinite type, through
      over-use of occCheckExpand in the kind of an /occurrence/ of a
      type variable.
      See Note [Occurrence checking: look inside kinds] in GHC.Core.Type
      This patch fixes the problem by making occCheckExpand less eager
      to expand synonyms in kinds.
      It also improves pretty printing of kinds, by *not* suppressing
      the kind on a tyvar-binder like
          (a :: Const Type b)
      where type Const p q = p.  Even though the kind of 'a' is Type,
      we don't want to suppress the kind ascription.  Example: the
      error message for polykinds/T18451{a,b}. See GHC.Core.TyCo.Ppr
      Note [Suppressing * kinds].
  16. 18 Jul, 2020 2 commits
    • Simon Peyton Jones's avatar
      Refactor the simplification of join binders · e504c913
      Simon Peyton Jones authored
      This MR (for #18449) refactors the Simplifier's treatment
      of join-point binders.
      Specifically, it puts together, into
      two currently-separate ways in which we adjust the type of
      a join point. As the comment says:
      -- (adjustJoinPointType mult new_res_ty join_id) does two things:
      --   1. Set the return type of the join_id to new_res_ty
      --      See Note [Return type for join points]
      --   2. Adjust the multiplicity of arrows in join_id's type, as
      --      directed by 'mult'. See Note [Scaling join point arguments]
      I think this actually fixes a latent bug, by ensuring that the
      seIdSubst and seInScope have the right multiplicity on the type
      of join points.
      I did some tidying up while I was at it.  No more
      setJoinResTy, or modifyJoinResTy: instead it's done locally in
    • Simon Peyton Jones's avatar
      Allow multiple case branches to have a higher rank type · bcb177dd
      Simon Peyton Jones authored
      As #18412 points out, it should be OK for multiple case alternatives
      to have a higher rank type, provided they are all the same.
      This patch implements that change.  It sweeps away
      GHC.Tc.Gen.Match.tauifyMultipleBranches, and friends, replacing it
      with an enhanced version of fillInferResult.
      The basic change to fillInferResult is to permit the case in which
      another case alternative has already filled in the result; and in
      that case simply unify.  It's very simple actually.
      See the new Note [fillInferResult] in TcMType
      Other refactoring:
      - Move all the InferResult code to one place, in GHC.Tc.Utils.TcMType
        (previously some of it was in Unify)
      - Move tcInstType and friends from TcMType to Instantiate, where it
        more properly belongs.  (TCMType was getting very long.)
  17. 03 Jul, 2020 1 commit
    • Simon Peyton Jones's avatar
      Improve handling of data type return kinds · 4bf18646
      Simon Peyton Jones authored
      Following a long conversation with Richard, this patch tidies up the
      handling of return kinds for data/newtype declarations (vanilla,
      family, and instance).
      I have substantially edited the Notes in TyCl, so they would
      bear careful reading.
      Fixes #18300, #18357
      In GHC.Tc.Instance.Family.newFamInst we were checking some Lint-like
      properties with ASSSERT.  Instead Richard and I have added
      a proper linter for axioms, and called it from lintGblEnv, which in
      turn is called in tcRnModuleTcRnM
      New tests (T18300, T18357) cause an ASSERT failure in HEAD.
  18. 28 Jun, 2020 2 commits
    • Jan Hrček's avatar
    • Ryan Scott's avatar
      Use NHsCoreTy to embed types into GND-generated code · 42f797b0
      Ryan Scott authored
      `GeneralizedNewtypeDeriving` is in the unique situation where it must
      produce an `LHsType GhcPs` from a Core `Type`. Historically, this was
      done with the `typeToLHsType` function, which walked over the entire
      `Type` and attempted to construct an `LHsType` with the same overall
      structure. `typeToLHsType` is quite complicated, however, and has
      been the subject of numerous bugs over the years (e.g., #14579).
      Luckily, there is an easier way to accomplish the same thing: the
      `XHsType` constructor of `HsType`. `XHsType` bundles an `NHsCoreTy`,
      which allows embedding a Core `Type` directly into an `HsType`,
      avoiding the need to laboriously convert from one to another (as
      `typeToLHsType` did). Moreover, renaming and typechecking an
      `XHsType` is simple, since one doesn't need to do anything to a
      Core `Type`...
      ...well, almost. For the reasons described in
      `Note [Typechecking NHsCoreTys]` in `GHC.Tc.Gen.HsType`, we must
      apply a substitution that we build from the local `tcl_env` type
      environment. But that's a relatively modest price to pay.
      Now that `GeneralizedNewtypeDeriving` uses `NHsCoreTy`, the
      `typeToLHsType` function no longer has any uses in GHC, so this patch
      rips it out. Some additional tweaks to `hsTypeNeedsParens` were
      necessary to make the new `-ddump-deriv` output correctly
      parenthesized, but other than that, this patch is quite
      This is a mostly internal refactoring, although it is likely that
      `GeneralizedNewtypeDeriving`-generated code will now need fewer
      language extensions in certain situations than it did before.
  19. 25 Jun, 2020 1 commit
    • Takenobu Tani's avatar
      Clean up haddock hyperlinks of GHC.* (part1) · c7dd6da7
      Takenobu Tani authored
      This updates haddock comments only.
      This patch focuses to update for hyperlinks in GHC API's haddock comments,
      because broken links especially discourage newcomers.
      This includes the following hierarchies:
        - GHC.Hs.*
        - GHC.Core.*
        - GHC.Stg.*
        - GHC.Cmm.*
        - GHC.Types.*
        - GHC.Data.*
        - GHC.Builtin.*
        - GHC.Parser.*
        - GHC.Driver.*
        - GHC top
  20. 17 Jun, 2020 2 commits
    • Krzysztof Gogolewski's avatar
      Various performance improvements · 6cb84c46
      Krzysztof Gogolewski authored
      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:
      Metric Increase:
    • Krzysztof Gogolewski's avatar
      Linear types (#15981) · 40fa237e
      Krzysztof Gogolewski authored
      This is the first step towards implementation of the linear types proposal
      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
      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.
  21. 13 Jun, 2020 1 commit
    • Ryan Scott's avatar
      Use HsForAllTelescope to avoid inferred, visible foralls · a31218f7
      Ryan Scott authored
      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.
  22. 10 Jun, 2020 2 commits
    • Simon Peyton Jones's avatar
      Implement cast worker/wrapper properly · 6d49d5be
      Simon Peyton Jones authored
      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:
    • Takenobu Tani's avatar
      Clarify leaf module names for new module hierarchy · 24879129
      Takenobu Tani authored
      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
  23. 05 Jun, 2020 1 commit
    • Simon Peyton Jones's avatar
      Simple subsumption · 2b792fac
      Simon Peyton Jones authored
      This patch simplifies GHC to use simple subsumption.
        Ticket #17775
      Implements GHC proposal #287
      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
        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:
      * 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:
      Metric Decrease:
      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)
  24. 21 May, 2020 1 commit
    • Gert-Jan Bottu's avatar
      Explicit Specificity · a9311cd5
      Gert-Jan Bottu authored
      Implementation for Ticket #16393.
      Explicit specificity allows users to manually create inferred type variables,
      by marking them with braces.
      This way, the user determines which variables can be instantiated through
      visible type application.
      The additional syntax is included in the parser, allowing users to write
      braces in type variable binders (type signatures, data constructors etc).
      This information is passed along through the renamer and verified in the
      type checker.
      The AST for type variable binders, data constructors, pattern synonyms,
      partial signatures and Template Haskell has been updated to include the
      specificity of type variables.
      Minor notes:
      - Bumps haddock submodule
      - Disables pattern match checking in GHC.Iface.Type with GHC 8.8
  25. 14 May, 2020 2 commits
  26. 06 May, 2020 1 commit
    • Ryan Scott's avatar
      Make isTauTy detect higher-rank contexts · edec6a6c
      Ryan Scott authored
      Previously, `isTauTy` would only detect higher-rank `forall`s, not
      higher-rank contexts, which led to some minor bugs observed
      in #18127. Easily fixed by adding a case for
      `(FunTy InvisArg _ _)`.
      Fixes #18127.
  27. 26 Apr, 2020 1 commit
  28. 18 Apr, 2020 1 commit
    • Sylvain Henry's avatar
      Modules (#13009) · 15312bbb
      Sylvain Henry authored
      * SysTools
      * Parser
      * GHC.Builtin
      * GHC.Iface.Recomp
      * Settings
      Update Haddock submodule
      Metric Decrease:
  29. 12 Apr, 2020 1 commit
    • Simon Peyton Jones's avatar
      Significant refactor of Lint · cd4f92b5
      Simon Peyton Jones authored
      This refactoring of Lint was triggered by #17923, which is
      fixed by this patch.
      The main change is this.  Instead of
         lintType :: Type -> LintM LintedKind
      we now have
         lintType :: Type -> LintM LintedType
      Previously, all of typeKind was effectively duplicate in lintType.
      Moreover, since we have an ambient substitution, we still had to
      apply the substition here and there, sometimes more than once. It
      was all very tricky, in the end, and made my head hurt.
      Now, lintType returns a fully linted type, with all substitutions
      performed on it.  This is much simpler.
      The same thing is needed for Coercions.  Instead of
        lintCoercion :: OutCoercion
                     -> LintM (LintedKind, LintedKind,
                               LintedType, LintedType, Role)
      we now have
        lintCoercion :: Coercion -> LintM LintedCoercion
      Much simpler!  The code is shorter and less bug-prone.
      There are a lot of knock on effects.  But life is now better.
      Metric Decrease:
  30. 10 Apr, 2020 1 commit
    • Sebastian Graf's avatar
      Special case `isConstraintKindCon` on `AlgTyCon` · 101fab6e
      Sebastian Graf authored
      Previously, the `tyConUnique` record selector would unfold into a huge
      case expression that would be inlined in all call sites, such as the
      `INLINE`-annotated `coreView`, see #18026. `constraintKindTyConKey` only
      occurs as the `Unique` of an `AlgTyCon` anyway, so we can make the code
      a lot more compact, but have to move it to GHC.Core.TyCon.
      Metric Decrease: