1. 24 Sep, 2020 1 commit
    • Simon Peyton Jones's avatar
      Implement Quick Look impredicativity · 97cff919
      Simon Peyton Jones authored
      This patch implements Quick Look impredicativity (#18126), sticking
      very closely to the design in
          A quick look at impredicativity, Serrano et al, ICFP 2020
      The main change is that a big chunk of GHC.Tc.Gen.Expr has been
      extracted to two new modules
      which deal with typechecking n-ary applications, and the head of
      such applications, respectively.  Both contain a good deal of
      Three other loosely-related changes are in this patch:
      * I implemented (partly by accident) points (2,3)) of the accepted GHC
        proposal "Clean up printing of foralls", namely
        (see #16320).
        In particular, see Note [TcRnExprMode] in GHC.Tc.Module
        - :type instantiates /inferred/, but not /specified/, quantifiers
        - :type +d instantiates /all/ quantifiers
        - :type +v is killed off
        That completes the implementation of the proposal,
        since point (1) was done in
          commit df084681
          Author: Krzysztof Gogolewski <krzysztof.gogolewski@tweag.io>
          Date:   Mon Feb 3 21:17:11 2020 +0100
          Always display inferred variables using braces
      * HsRecFld (which the renamer introduces for record field selectors),
        is now preserved by the typechecker, rather than being rewritten
        back to HsVar.  This is more uniform, and turned out to be more
        convenient in the new scheme of things.
      * The GHCi debugger uses a non-standard unification that allows the
        unification variables to unify with polytypes.  We used to hack
        this by using ImpredicativeTypes, but that doesn't work anymore
        so I introduces RuntimeUnkTv.  See Note [RuntimeUnkTv] in
      Updates haddock submodule.
      WARNING: this patch won't validate on its own.  It was too
      hard to fully disentangle it from the following patch, on
      type errors and kind generalisation.
      Changes to tests
      * Fixes #9730 (test added)
      * Fixes #7026 (test added)
      * Fixes most of #8808, except function `g2'` which uses a
        section (which doesn't play with QL yet -- see #18126)
        Test added
      * Fixes #1330. NB Church1.hs subsumes Church2.hs, which is now deleted
      * Fixes #17332 (test added)
      * Fixes #4295
      * This patch makes typecheck/should_run/T7861 fail.
        But that turns out to be a pre-existing bug: #18467.
        So I have just made T7861 into expect_broken(18467)
  2. 17 Sep, 2020 2 commits
  3. 09 Sep, 2020 2 commits
    • Ben Gamari's avatar
      utils: Bump cabal-version of hp2ps and unlit · 291a15dd
      Ben Gamari authored
    • Alan Zimmerman's avatar
      Remove GENERATED pragma, as it is not being used · 7911d0d9
      Alan Zimmerman authored
      @alanz pointed out on ghc-devs that the payload of this pragma does
      not appear to be used anywhere.
      I (@bgamari) did some digging and traced the pragma's addition back to
      d386e0d2 (way back in 2006!).
      It appears that it was intended to be used by code generators for use
      in informing the code coveraging checker about generated code
      provenance. When it was added it used the pragma's "payload" fields as
      source location information to build an "ExternalBox". However, it
      looks like this was dropped a year later in 55a5d8d9.  At this point
      it seems like the pragma serves no useful purpose.
      Given that it also is not documented, I think we should remove it.
      Updates haddock submodule
      Closes #18639
  4. 01 Sep, 2020 1 commit
    • Sylvain Henry's avatar
      Remove "Ord FastString" instance · 4b4fbc58
      Sylvain Henry authored
      FastStrings can be compared in 2 ways: by Unique or lexically. We don't
      want to bless one particular way with an "Ord" instance because it leads
      to bugs (#18562) or to suboptimal code (e.g. using lexical comparison
      while a Unique comparison would suffice).
      UTF-8 encoding has the advantage that sorting strings by their encoded
      bytes also sorts them by their Unicode code points, without having to
      decode the actual code points. BUT GHC uses Modified UTF-8 which
      diverges from UTF-8 by encoding \0 as 0xC080 instead of 0x00 (to avoid
      null bytes in the middle of a String so that the string can still be
      null-terminated). This patch adds a new `utf8CompareShortByteString`
      function that performs sorting by bytes but that also takes Modified
      UTF-8 into account. It is much more performant than decoding the strings
      into [Char] to perform comparisons (which we did in the previous patch).
      Bump haddock submodule
  5. 28 Aug, 2020 1 commit
    • Krzysztof Gogolewski's avatar
      Add missing primop documentation (#18454) · c6f50cea
      Krzysztof Gogolewski authored
      - Add three pseudoops to primops.txt.pp, so that Haddock renders
        the documentation
      - Update comments
      - Remove special case for "->" - it's no longer exported from GHC.Prim
      - Remove reference to Note [Compiling GHC.Prim] - the ad-hoc fix is no
        longer there after updates to levity polymorphism.
      - Document GHC.Prim
      - Remove the comment that lazy is levity-polymorphic.
        As far as I can tell, it never was: in 80e39963,
        only the unfolding was given an open type variable.
      - Remove haddock hack in GHC.Magic - no longer neccessary after
        adding realWorld# to primops.txt.pp.
  6. 26 Aug, 2020 1 commit
    • Krzysztof Gogolewski's avatar
      primops: Remove Monadic and Dyadic categories · 770100e0
      Krzysztof Gogolewski authored
      There were four categories of primops: Monadic, Dyadic, Compare, GenPrimOp.
      The compiler does not treat Monadic and Dyadic in any special way,
      we can just replace them with GenPrimOp.
      Compare is still used in isComparisonPrimOp.
  7. 14 Aug, 2020 1 commit
  8. 13 Aug, 2020 1 commit
    • Sylvain Henry's avatar
      Add HomeUnit type · ffc0d578
      Sylvain Henry authored
      Since Backpack the "home unit" is much more involved than what it was
      before (just an identifier obtained with `-this-unit-id`). Now it is
      used in conjunction with `-component-id` and `-instantiated-with` to
      configure module instantiations and to detect if we are type-checking an
      indefinite unit or compiling a definite one.
      This patch introduces a new HomeUnit datatype which is much easier to
      understand. Moreover to make GHC support several packages in the same
      instances, we will need to handle several HomeUnits so having a
      dedicated (documented) type is helpful.
      Finally in #14335 we will also need to handle the case where we have no
      HomeUnit at all because we are only loading existing interfaces for
      plugins which live in a different space compared to units used to
      produce target code. Several functions will have to be refactored to
      accept "Maybe HomeUnit" parameters instead of implicitly querying the
      HomeUnit fields in DynFlags. Having a dedicated type will make this
      Bump haddock submodule
  9. 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
  10. 11 Aug, 2020 2 commits
  11. 08 Aug, 2020 1 commit
  12. 05 Aug, 2020 1 commit
  13. 25 Jul, 2020 4 commits
  14. 23 Jul, 2020 2 commits
  15. 21 Jul, 2020 1 commit
    • Vladislav Zavialov's avatar
      Accumulate Haddock comments in P (#17544, #17561, #8944) · 19e80b9a
      Vladislav Zavialov authored
      Haddock comments are, first and foremost, comments. It's very annoying
      to incorporate them into the grammar. We can take advantage of an
      important property: adding a Haddock comment does not change the parse
      tree in any way other than wrapping some nodes in HsDocTy and the like
      (and if it does, that's a bug).
      This patch implements the following:
      * Accumulate Haddock comments with their locations in the P monad.
        This is handled in the lexer.
      * After parsing, do a pass over the AST to associate Haddock comments
        with AST nodes using location info.
      * Report the leftover comments to the user as a warning (-Winvalid-haddock).
  16. 18 Jul, 2020 1 commit
  17. 15 Jul, 2020 6 commits
  18. 12 Jul, 2020 1 commit
    • Andreas Klebinger's avatar
      Give Uniq[D]FM a phantom type for its key. · c4de6a7a
      Andreas Klebinger authored
      This fixes #17667 and should help to avoid such issues going forward.
      The changes are mostly mechanical in nature. With two notable
      * The register allocator.
        The register allocator references registers by distinct uniques.
        However they come from the types of VirtualReg, Reg or Unique in
        various places. As a result we sometimes cast the key type of the
        map and use functions which operate on the now typed map but take
        a raw Unique as actual key. The logic itself has not changed it
        just becomes obvious where we do so now.
      * <Type>Env Modules.
      As an example a ClassEnv is currently queried using the types `Class`,
      `Name`, and `TyCon`. This is safe since for a distinct class value all
      these expressions give the same unique.
          getUnique cls
          getUnique (classTyCon cls)
          getUnique (className cls)
          getUnique (tcName $ classTyCon cls)
      This is for the most part contained within the modules defining the
      interface. However it requires us to play dirty when we are given a
      `Name` to lookup in a `UniqFM Class a` map. But again the logic did
      not change and it's for the most part hidden behind the Env Module.
      Some of these cases could be avoided by refactoring but this is left
      for future work.
      We also bump the haddock submodule as it uses UniqFM.
  19. 01 Jul, 2020 1 commit
  20. 26 Jun, 2020 1 commit
    • Matthías Páll Gissurarson's avatar
      Implement the proposed -XQualifiedDo extension · 9ee58f8d
      Matthías Páll Gissurarson authored
      Co-authored-by: default avatarFacundo Domínguez <facundo.dominguez@tweag.io>
      QualifiedDo is implemented using the same placeholders for operation names in
      the AST that were devised for RebindableSyntax. Whenever the renamer checks
      which names to use for do syntax, it first checks if the do block is qualified
      (e.g. M.do { stmts }), in which case it searches for qualified names in
      the module M.
      This allows users to write
          {-# LANGUAGE QualifiedDo #-}
          import qualified SomeModule as M
          f x = M.do           -- desugars to:
            y <- M.return x    -- M.return x M.>>= \y ->
            M.return y         -- M.return y M.>>
            M.return y         -- M.return y
      See Note [QualifiedDo] and the users' guide for more details.
      Issue #18214
      Since we change the constructors `ITdo` and `ITmdo` to carry the new module
      name, we need to bump the haddock submodule to account or the new shape of
      these constructors.
  21. 25 Jun, 2020 1 commit
    • wz1000's avatar
      Export everything from HsToCore. · 90f43872
      wz1000 authored
      This lets us reuse these functions in haddock, avoiding synchronization bugs.
      Also fixed some divergences with haddock in that file
      Updates haddock submodule
  22. 17 Jun, 2020 2 commits
    • 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.
    • Ben Gamari's avatar
      base: Bump to · 7faa4509
      Ben Gamari authored
  23. 13 Jun, 2020 3 commits
    • 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.
    • Sylvain Henry's avatar
      Bump haddock submodule and allow metric decrease · 456e17f0
      Sylvain Henry authored
      Metric Decrease:
      Metric Increase:
    • Sylvain Henry's avatar
      Rename Package into Unit (2) · 653d17bd
      Sylvain Henry authored
      * rename PackageState into UnitState
      * rename findWiredInPackages into findWiredInUnits
      * rename lookupModuleInAll[Packages,Units]
      * etc.
  24. 09 Jun, 2020 1 commit
    • Ryan Scott's avatar
      Make GADT constructors adhere to the forall-or-nothing rule properly · 72c7fe9a
      Ryan Scott authored
      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.
  25. 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)