1. 14 Jun, 2019 1 commit
    • Andrew Martin's avatar
      Implement the -XUnliftedNewtypes extension. · effdd948
      Andrew Martin authored
      GHC Proposal: 0013-unlifted-newtypes.rst
      Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/98
      Issues: #15219, #1311, #13595, #15883
      Implementation Details:
        Note [Implementation of UnliftedNewtypes]
        Note [Unifying data family kinds]
        Note [Compulsory newtype unfolding]
      
      This patch introduces the -XUnliftedNewtypes extension. When this
      extension is enabled, GHC drops the restriction that the field in
      a newtype must be of kind (TYPE 'LiftedRep). This allows types
      like Int# and ByteArray# to be used in a newtype. Additionally,
      coerce is made levity-polymorphic so that it can be used with
      newtypes over unlifted types.
      
      The bulk of the changes are in TcTyClsDecls.hs. With -XUnliftedNewtypes,
      getInitialKind is more liberal, introducing a unification variable to
      return the kind (TYPE r0) rather than just returning (TYPE 'LiftedRep).
      When kind-checking a data constructor with kcConDecl, we attempt to
      unify the kind of a newtype with the kind of its fie...
      effdd948
  2. 29 May, 2019 1 commit
    • Oleg Grenrus's avatar
      Fix some warnings in users_guide (incl #16640) · 5bfd28f5
      Oleg Grenrus authored
      - short underline
      - :ghc-flag:, not :ghc-flags:
      - :since: have to be separate
      - newline before code block
      - workaround anchor generation so
      
          - pragma:SPECIALISE
          - pragma:SPECIALIZE-INLINE
          - pragma:SPECIALIZE-inline
      
        are different anchors, not all the same `pragma:SPECIALIZE`
      5bfd28f5
  3. 22 May, 2019 1 commit
    • Ryan Scott's avatar
      Use HsTyPats in associated type family defaults · 6efe04de
      Ryan Scott authored
      Associated type family default declarations behave strangely in a
      couple of ways:
      
      1. If one tries to bind the type variables with an explicit `forall`,
         the `forall`'d part will simply be ignored. (#16110)
      2. One cannot use visible kind application syntax on the left-hand
         sides of associated default equations, unlike every other form
         of type family equation. (#16356)
      
      Both of these issues have a common solution. Instead of using
      `LHsQTyVars` to represent the left-hand side arguments of an
      associated default equation, we instead use `HsTyPats`, which is what
      other forms of type family equations use. In particular, here are
      some highlights of this patch:
      
      * `FamEqn` is no longer parameterized by a `pats` type variable, as
        the `feqn_pats` field is now always `HsTyPats`.
      * The new design for `FamEqn` in chronicled in
        `Note [Type family instance declarations in HsSyn]`.
      * `TyFamDefltEqn` now becomes the same thing as `TyFamInstEqn`. This
        means that many of `TyFamDefltEqn`'s code paths can now reuse the
        code paths for `TyFamInstEqn`, resulting in substantial
        simplifications to various parts of the code dealing with
        associated type family defaults.
      
      Fixes #16110 and #16356.
      6efe04de
  4. 14 May, 2019 1 commit
    • Vladislav Zavialov's avatar
      Guard CUSKs behind a language pragma · a5fdd185
      Vladislav Zavialov authored
      GHC Proposal #36 describes a transition plan away from CUSKs and to
      top-level kind signatures:
      
      1. Introduce a new extension, -XCUSKs, on by default, that detects CUSKs
         as they currently exist.
      2. We turn off the -XCUSKs extension in a few releases and remove it
         sometime thereafter.
      
      This patch implements phase 1 of this plan, introducing a new language
      extension to control whether CUSKs are enabled. When top-level kind
      signatures are implemented, we can transition to phase 2.
      a5fdd185
  5. 08 May, 2019 1 commit
  6. 05 May, 2019 1 commit
  7. 03 May, 2019 1 commit
    • Ryan Scott's avatar
      Make equality constraints in kinds invisible · cc495d57
      Ryan Scott authored
      Issues #12102 and #15872 revealed something strange about the way GHC
      handles equality constraints in kinds: it treats them as _visible_
      arguments! This causes a litany of strange effects, from strange
      error messages
      (ghc/ghc#12102 (comment 169035))
      to bizarre `Eq#`-related things leaking through to GHCi output, even
      without any special flags enabled.
      
      This patch is an attempt to contain some of this strangeness.
      In particular:
      
      * In `TcHsType.etaExpandAlgTyCon`, we propagate through the
        `AnonArgFlag`s of any `Anon` binders. Previously, we were always
        hard-coding them to `VisArg`, which meant that invisible binders
        (like those whose kinds were equality constraint) would mistakenly
        get flagged as visible.
      * In `ToIface.toIfaceAppArgsX`, we previously assumed that the
        argument to a `FunTy` always corresponding to a `Required`
        argument. We now dispatch on the `FunTy`'s `AnonArgFlag` and map
        `VisArg` to `Required` and `Inv...
      cc495d57
  8. 19 Apr, 2019 1 commit
    • Alec Theriault's avatar
      TH: make `Lift` and `TExp` levity-polymorphic · 57cf1133
      Alec Theriault authored
      Besides the obvious benefits of being able to manipulate `TExp`'s of
      unboxed types, this also simplified `-XDeriveLift` all while making
      it more capable.
      
        * `ghc-prim` is explicitly depended upon by `template-haskell`
      
        * The following TH things are parametrized over `RuntimeRep`:
      
            - `TExp(..)`
            - `unTypeQ`
            - `unsafeTExpCoerce`
            - `Lift(..)`
      
        * The following instances have been added to `Lift`:
      
            - `Int#`, `Word#`, `Float#`, `Double#`, `Char#`, `Addr#`
            - unboxed tuples of lifted types up to arity 7
            - unboxed sums of lifted types up to arity 7
      
          Ideally we would have levity-polymorphic _instances_ of unboxed
          tuples and sums.
      
        * The code generated by `-XDeriveLift` uses expression quotes
          instead of generating large amounts of TH code and having
          special hard-coded cases for some unboxed types.
      57cf1133
  9. 03 Apr, 2019 2 commits
  10. 25 Mar, 2019 1 commit
    • Rinat Striungis's avatar
      User's Guide: extensions compatibility · d763b2e7
      Rinat Striungis authored
      Adds the mention that extensions "AllowAmbiguousTypes" and "RankNTypes"
      are not always compatible with each other.
      Specifies the conditions and causes of failing in resolving
      of ambiguity.
      d763b2e7
  11. 20 Mar, 2019 1 commit
    • Takenobu Tani's avatar
      users-guide: Update Wiki URLs to point to GitLab · 89a201e8
      Takenobu Tani authored
      The user's guide uses the `ghc-wiki` macro, and substitution rules
      are complicated. So I manually edited `.rst` files without sed.
      
      I changed `Commentary/Latedmd` only to a different page.
      It is more appropriate as an example.
      
      [ci skip]
      89a201e8
  12. 15 Mar, 2019 1 commit
  13. 01 Mar, 2019 1 commit
    • Ryan Scott's avatar
      Visible dependent quantification · c26d299d
      Ryan Scott authored
      This implements GHC proposal 35
      (https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0035-forall-arrow.rst)
      by adding the ability to write kinds with
      visible dependent quantification (VDQ).
      
      Most of the work for supporting VDQ was actually done _before_ this
      patch. That is, GHC has been able to reason about kinds with VDQ for
      some time, but it lacked the ability to let programmers directly
      write these kinds in the source syntax. This patch is primarly about
      exposing this ability, by:
      
      * Changing `HsForAllTy` to add an additional field of type
        `ForallVisFlag` to distinguish between invisible `forall`s (i.e,
        with dots) and visible `forall`s (i.e., with arrows)
      * Changing `Parser.y` accordingly
      
      The rest of the patch mostly concerns adding validity checking to
      ensure that VDQ is never used in the type of a term (as permitting
      this would require full-spectrum dependent types). This is
      accomplished by:
      
      * Adding a `vdqAllowed` predicate to `TcValidity`.
      * Introducing `splitLHsSigmaTyInvis`, a variant of `splitLHsSigmaTy`
        that only splits invisible `forall`s. This function is used in
        certain places (e.g., in instance declarations) to ensure that GHC
        doesn't try to split visible `forall`s (e.g., if it tried splitting
        `instance forall a -> Show (Blah a)`, then GHC would mistakenly
        allow that declaration!)
      
      This also updates Template Haskell by introducing a new `ForallVisT`
      constructor to `Type`.
      
      Fixes #16326. Also fixes #15658 by documenting this feature in the
      users' guide.
      c26d299d
  14. 27 Feb, 2019 1 commit
    • Vladislav Zavialov's avatar
      Treat kind/type variables identically, demolish FKTV · 5bc195b1
      Vladislav Zavialov authored
      Implements GHC Proposal #24: .../ghc-proposals/blob/master/proposals/0024-no-kind-vars.rst
      Fixes Trac #16334, Trac #16315
      
      With this patch, scoping rules for type and kind variables have been
      unified: kind variables no longer receieve special treatment. This
      simplifies both the language and the implementation.
      
      User-facing changes
      -------------------
      
      * Kind variables are no longer implicitly quantified when an explicit
        forall is used:
      
          p ::             Proxy (a :: k)    -- still accepted
          p :: forall k a. Proxy (a :: k)    -- still accepted
          p :: forall   a. Proxy (a :: k)    -- no longer accepted
      
        In other words, now we adhere to the "forall-or-nothing" rule more
        strictly.
      
        Related function: RnTypes.rnImplicitBndrs
      
      * The -Wimplicit-kind-vars warning has been deprecated.
      
      * Kind variables are no longer implicitly quantified in constructor
        declarations:
      
          data T a        = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- no longer accepted
          data T (a :: k) = T1 (S (a :: k) | forall (b::k). T2 (S b)  -- still accepted
      
        Related function: RnTypes.extractRdrKindSigVars
      
      * Implicitly quantified kind variables are no longer put in front of
        other variables:
      
          f :: Proxy (a :: k) -> Proxy (b :: j)
      
          f :: forall k j (a :: k) (b :: j). Proxy a -> Proxy b   -- old order
          f :: forall k (a :: k) j (b :: j). Proxy a -> Proxy b   -- new order
      
        This is a breaking change for users of TypeApplications. Note that
        we still respect the dpendency order: 'k' before 'a', 'j' before 'b'.
        See "Ordering of specified variables" in the User's Guide.
      
        Related function: RnTypes.rnImplicitBndrs
      
      * In type synonyms and type family equations, free variables on the RHS
        are no longer implicitly quantified unless used in an outermost kind
        annotation:
      
          type T = Just (Nothing :: Maybe a)         -- no longer accepted
          type T = Just Nothing :: Maybe (Maybe a)   -- still accepted
      
        The latter form is a workaround due to temporary lack of an explicit
        quantification method. Ideally, we would write something along these
        lines:
      
          type T @a = Just (Nothing :: Maybe a)
      
        Related function: RnTypes.extractHsTyRdrTyVarsKindVars
      
      * Named wildcards in kinds are fixed (Trac #16334):
      
          x :: (Int :: _t)    -- this compiles, infers (_t ~ Type)
      
        Related function: RnTypes.partition_nwcs
      
      Implementation notes
      --------------------
      
      * One of the key changes is the removal of FKTV in RnTypes:
      
        - data FreeKiTyVars = FKTV { fktv_kis    :: [Located RdrName]
        -                          , fktv_tys    :: [Located RdrName] }
        + type FreeKiTyVars = [Located RdrName]
      
        We used to keep track of type and kind variables separately, but
        now that they are on equal footing when it comes to scoping, we
        can put them in the same list.
      
      * extract_lty and family are no longer parametrized by TypeOrKind,
        as we now do not distinguish kind variables from type variables.
      
      * PatSynExPE and the related Note [Pattern synonym existentials do not scope]
        have been removed (Trac #16315). With no implicit kind quantification,
        we can no longer trigger the error.
      
      * reportFloatingKvs and the related Note [Free-floating kind vars]
        have been removed. With no implicit kind quantification,
        we can no longer trigger the error.
      5bc195b1
  15. 24 Feb, 2019 3 commits
    • Vladislav Zavialov's avatar
      ae7d1ff6
    • Vladislav Zavialov's avatar
      User's Guide: update info on kind inference · 88970187
      Vladislav Zavialov authored
      We no longer put class variables in front,
      see "Taming the Kind Inference Monster"
      
      (also fix some markup issues)
      88970187
    • Simon Peyton Jones's avatar
      Add AnonArgFlag to FunTy · 6cce36f8
      Simon Peyton Jones authored
      The big payload of this patch is:
      
        Add an AnonArgFlag to the FunTy constructor
        of Type, so that
          (FunTy VisArg   t1 t2) means (t1 -> t2)
          (FunTy InvisArg t1 t2) means (t1 => t2)
      
      The big payoff is that we have a simple, local test to make
      when decomposing a type, leading to many fewer calls to
      isPredTy. To me the code seems a lot tidier, and probably
      more efficient (isPredTy has to take the kind of the type).
      
      See Note [Function types] in TyCoRep.
      
      There are lots of consequences
      
      * I made FunTy into a record, so that it'll be easier
        when we add a linearity field, something that is coming
        down the road.
      
      * Lots of code gets touched in a routine way, simply because it
        pattern matches on FunTy.
      
      * I wanted to make a pattern synonym for (FunTy2 arg res), which
        picks out just the argument and result type from the record. But
        alas the pattern-match overlap checker has a heart attack, and
        either reports false positives, or takes too long.  In the end
        I gave up on pattern synonyms.
      
        There's some commented-out code in TyCoRep that shows what I
        wanted to do.
      
      * Much more clarity about predicate types, constraint types
        and (in particular) equality constraints in kinds.  See TyCoRep
        Note [Types for coercions, predicates, and evidence]
        and Note [Constraints in kinds].
      
        This made me realise that we need an AnonArgFlag on
        AnonTCB in a TyConBinder, something that was really plain
        wrong before. See TyCon Note [AnonTCB InivsArg]
      
      * When building function types we must know whether we
        need VisArg (mkVisFunTy) or InvisArg (mkInvisFunTy).
        This turned out to be pretty easy in practice.
      
      * Pretty-printing of types, esp in IfaceType, gets
        tidier, because we were already recording the (->)
        vs (=>) distinction in an ad-hoc way.  Death to
        IfaceFunTy.
      
      * mkLamType needs to keep track of whether it is building
        (t1 -> t2) or (t1 => t2).  See Type
        Note [mkLamType: dictionary arguments]
      
      Other minor stuff
      
      * Some tidy-up in validity checking involving constraints;
        Trac #16263
      6cce36f8
  16. 08 Feb, 2019 1 commit
  17. 23 Jan, 2019 1 commit
  18. 03 Jan, 2019 1 commit
    • My Nguyen's avatar
      Visible kind application · 17bd1635
      My Nguyen authored
      Summary:
      This patch implements visible kind application (GHC Proposal 15/#12045), as well as #15360 and #15362.
      It also refactors unnamed wildcard handling, and requires that type equations in type families in Template Haskell be
      written with full type on lhs. PartialTypeSignatures are on and warnings are off automatically with visible kind
      application, just like in term-level.
      
      There are a few remaining issues with this patch, as documented in
      ticket #16082.
      
      Includes a submodule update for Haddock.
      
      Test Plan: Tests T12045a/b/c/TH1/TH2, T15362, T15592a
      
      Reviewers: simonpj, goldfire, bgamari, alanz, RyanGlScott, Iceland_jack
      
      Subscribers: ningning, Iceland_jack, RyanGlScott, int-index, rwbarton, mpickering, carter
      
      GHC Trac Issues: `#12045`, `#15362`, `#15592`, `#15788`, `#15793`, `#15795`, `#15797`, `#15799`, `#15801`, `#15807`, `#15816`
      
      Differential Revision: https://phabricator.haskell.org/D5229
      17bd1635
  19. 21 Dec, 2018 1 commit
  20. 11 Dec, 2018 1 commit
  21. 07 Dec, 2018 1 commit
    • Ryan Scott's avatar
      Fix #12102/#15872 by removing outdated users' guide prose · 73cce63f
      Ryan Scott authored
      Summary:
      In the beginning, #12102 (and #15872, which is of a similar
      ilk) were caused by a poor, confused user trying to use code that
      looks like this (with a constraint in the kind of a data type):
      
      ```lang=haskell
      type family IsTypeLit a where
        IsTypeLit Nat    = 'True
        IsTypeLit Symbol = 'True
        IsTypeLit a      = 'False
      
      data T :: forall a. (IsTypeLit a ~ 'True) => a -> * where
        MkNat    :: T 42
        MkSymbol :: T "Don't panic!"
      ```
      
      Many bizarre GHC quirks (documented in those tickets) arose from
      this sort of construction. Ultimately, the use of constraints in
      data type kinds like this has made a lot of people very confused and
      been widely regarded as a bad move.
      
      Commit 2257a86d finally put this
      feature out of its misery, so now the code above simply errors with
      `Illegal constraint in a kind`. As a result, the aforementioned
      tickets are moot, so this patch wraps a bow on the whole thing by:
      
      1. Removing the (now outdated) section on constraints in data type
         kinds from the users' guide, and
      2. Adding a test case to test this code path.
      
      Test Plan: make test TEST=T12102
      
      Reviewers: goldfire, simonpj, bgamari, tdammers
      
      Reviewed By: tdammers
      
      Subscribers: tdammers, rwbarton, carter
      
      GHC Trac Issues: #12102, #15872
      
      Differential Revision: https://phabricator.haskell.org/D5397
      73cce63f
  22. 29 Nov, 2018 1 commit
    • mayac's avatar
      Fix #15828, from `More explicit foralls` · fe57a5ba
      mayac authored
      Summary:
      Fix a bug in commit 12eeb9 which permits the following:
      
      ```
      class C a where
        type T a b
      instance C (Maybe a) where
        type forall a b. T (Maybe a) b = b
      ```
      
      where instead, the user should write:
      
      ```
      instance C (Maybe a) where
        type forall b. T (Maybe a) b = b
      ```
      
      Update the users guide to discuss scoping of type variables in
      explicit foralls in type family instances.
      
      Test Plan: validate
      
      Reviewers: bgamari, goldfire, monoidal
      
      Reviewed By: goldfire
      
      Subscribers: monoidal, rwbarton, carter
      
      GHC Trac Issues: #15828
      
      Differential Revision: https://phabricator.haskell.org/D5283
      fe57a5ba
  23. 17 Nov, 2018 2 commits
  24. 02 Nov, 2018 1 commit
  25. 29 Oct, 2018 2 commits
    • Ben Gamari's avatar
      users guide: Introduce :pragma: directive · e35ed9dc
      Ben Gamari authored
      e35ed9dc
    • Tobias Dammers's avatar
      Finish fix for #14880. · 5e45ad10
      Tobias Dammers authored
      The real change that fixes the ticket is described in
      Note [Naughty quantification candidates] in TcMType.
      
      Fixing this required reworking candidateQTyVarsOfType, the function
      that extracts free variables as candidates for quantification.
      One consequence is that we now must be more careful when quantifying:
      any skolems around must be quantified manually, and quantifyTyVars
      will now only quantify over metavariables. This makes good sense,
      as skolems are generally user-written and are listed in the AST.
      
      As a bonus, we now have more control over the ordering of such
      skolems.
      
      Along the way, this commit fixes #15711 and refines the fix
      to #14552 (by accepted a program that was previously rejected,
      as we can now accept that program by zapping variables to Any).
      
      This commit also does a fair amount of rejiggering kind inference
      of datatypes. Notably, we now can skip the generalization step
      in kcTyClGroup for types with CUSKs, because we get the
      kind right the first time. This commit also thus fixes #15743 and
       #15592, which both concern datatype kind generalisation.
      (#15591 is also very relevant.) For this aspect of the commit, see
      Note [Required, Specified, and Inferred in types] in TcTyClsDecls.
      
      Test cases: dependent/should_fail/T14880{,-2},
                  dependent/should_fail/T15743[cd]
                  dependent/should_compile/T15743{,e}
                  ghci/scripts/T15743b
                  polykinds/T15592
                  dependent/should_fail/T15591[bc]
                  ghci/scripts/T15591
      5e45ad10
  26. 27 Oct, 2018 1 commit
    • mayac's avatar
      More explicit foralls (GHC Proposal 0007) · 512eeb9b
      mayac authored
      Allow the user to explicitly bind type/kind variables in type and data
      family instances (including associated instances), closed type family
      equations, and RULES pragmas. Follows the specification of GHC
      Proposal 0007, also fixes #2600. Advised by Richard Eisenberg.
      
      This modifies the Template Haskell AST -- old code may break!
      
      Other Changes:
      - convert HsRule to a record
      - make rnHsSigWcType more general
      - add repMaybe to DsMeta
      
      Includes submodule update for Haddock.
      
      Test Plan: validate
      
      Reviewers: goldfire, bgamari, alanz
      
      Subscribers: simonpj, RyanGlScott, goldfire, rwbarton,
                   thomie, mpickering, carter
      
      GHC Trac Issues: #2600, #14268
      
      Differential Revision: https://phabricator.haskell.org/D4894
      512eeb9b
  27. 25 Oct, 2018 1 commit
  28. 04 Oct, 2018 1 commit
    • Alec Theriault's avatar
      Set `infixr -1 ->` · 251e3424
      Alec Theriault authored
      Summary:
      This simply makes explicit what is already the case. Due to special
      treatment in the parser, `->` has the lowest fixity. This patch propagates
      that information to:
      
        * GHCi, where `:info ->` now return the right fixity
        * TH, where `reifyFixity` returns the right fixity
        * the generated sources for `GHC.Prim`
      
      See #15235.
      
      Test Plan: make test
      
      Reviewers: bgamari, alanz, RyanGlScott
      
      Reviewed By: RyanGlScott
      
      Subscribers: int-index, RyanGlScott, rwbarton, mpickering, carter
      
      GHC Trac Issues: #15235
      
      Differential Revision: https://phabricator.haskell.org/D5199
      251e3424
  29. 01 Oct, 2018 1 commit
    • Ryan Scott's avatar
      Quantify class variables first in associated families' kinds · a57fa247
      Ryan Scott authored
      Summary:
      Previously, `kcLHsQTyVars` would always quantify class-bound
      variables invisibly in the kinds of associated types, resulting in
      #15591. We counteract this by explicitly passing the class-bound
      variables to `kcLHsQTyVars` and quantifying over the ones that are
      mentioned in the associated type such that (1) they are specified,
      and (2) they come before other kind variables.
      See `Note [Kind variable ordering for associated types]`.
      
      Test Plan: make test TEST=T15591
      
      Reviewers: goldfire, simonpj, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, carter
      
      GHC Trac Issues: #15591
      
      Differential Revision: https://phabricator.haskell.org/D5159
      a57fa247
  30. 20 Sep, 2018 1 commit
  31. 18 Sep, 2018 1 commit
  32. 17 Sep, 2018 1 commit
  33. 13 Sep, 2018 1 commit
  34. 07 Sep, 2018 2 commits
    • Takenobu Tani's avatar
      users-guide: Disable syntax highlighting · 2b6694a5
      Takenobu Tani authored
      Summary:
      I disabled syntax highlighting for NumericUnderscores extension.
      
      Because pygments does not yet correspond to syntax rule for NumericUnderscores.
      (Sphinx uses pygments as the syntax highlighting.)
      
      I've sent a pull-request to pygments project[1].
      But development of pygments has been suspended since 2017 March.
      
      [1]: https://bitbucket.org/birkenfeld/pygments-main/pull-requests/
             745/fix-haskell-lexer-for-numeric-literals/diff
      
      [ci skip]
      
      Test Plan: build
      
      Reviewers: bgamari, monoidal
      
      Reviewed By: monoidal
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5120
      2b6694a5
    • Krzysztof Gogolewski's avatar
      Documentation tweaks · 4caad166
      Krzysztof Gogolewski authored
      Summary:
      - Mention static pointers in "stolen syntax"
      - Suggest importing Constraint and IsString from Data.* instead of GHC.*
      - Remove obsolete SPECIALISE syntax; it was removed in or before 1999
        (d66d409b)
      - Fix link in pattern signatures
      
      Test Plan: build
      
      Reviewers: bgamari, takenobu
      
      Reviewed By: takenobu
      
      Subscribers: rwbarton, carter
      
      Differential Revision: https://phabricator.haskell.org/D5132
      4caad166