1. 28 Nov, 2019 2 commits
    • Vladislav Zavialov's avatar
      Factor out HsSCC/HsCoreAnn/HsTickPragma into HsPragE · 6985e0fc
      Vladislav Zavialov authored
      This is a refactoring with no user-visible changes (except for GHC API
      users). Consider the HsExpr constructors that correspond to user-written
      pragmas:
      
        HsSCC         representing  {-# SCC ... #-}
        HsCoreAnn     representing  {-# CORE ... #-}
        HsTickPragma  representing  {-# GENERATED ... #-}
      
      We can factor them out into a separate datatype, HsPragE. It makes the
      code a bit tidier, especially in the parser.
      
      Before this patch:
      
        hpc_annot :: { Located ( (([AddAnn],SourceText),(StringLiteral,(Int,Int),(Int,Int))),
                                 ((SourceText,SourceText),(SourceText,SourceText))
                               ) }
      
      After this patch:
      
        prag_hpc :: { Located ([AddAnn], HsPragE GhcPs) }
      6985e0fc
    • Brian Wignall's avatar
      3748ba3a
  2. 03 Nov, 2019 1 commit
    • Sebastian Graf's avatar
      Separate `LPat` from `Pat` on the type-level · 182b1199
      Sebastian Graf authored
      Since the Trees That Grow effort started, we had `type LPat = Pat`.
      This is so that `SrcLoc`s would only be annotated in GHC's AST, which is
      the reason why all GHC passes use the extension constructor `XPat` to
      attach source locations. See #15495 for the design discussion behind
      that.
      
      But now suddenly there are `XPat`s everywhere!
      There are several functions which dont't cope with `XPat`s by either
      crashing (`hsPatType`) or simply returning incorrect results
      (`collectEvVarsPat`).
      
      This issue was raised in #17330. I also came up with a rather clean and
      type-safe solution to the problem: We define
      
      ```haskell
      type family XRec p (f :: * -> *) = r | r -> p f
      type instance XRec (GhcPass p) f = Located (f (GhcPass p))
      type instance XRec TH          f =          f p
      type LPat p = XRec p Pat
      ```
      
      This is a rather modular embedding of the old "ping-pong" style, while
      we only pay for the `Located` wrapper within GHC. No ping-ponging in
      a potential Template Haskell AST, for example. Yet, we miss no case
      where we should've handled a `SrcLoc`: `hsPatType` and
      `collectEvVarsPat` are not callable at an `LPat`.
      
      Also, this gets rid of one indirection in `Located` variants:
      Previously, we'd have to go through `XPat` and `Located` to get from
      `LPat` to the wrapped `Pat`. Now it's just `Located` again.
      
      Thus we fix #17330.
      182b1199
  3. 28 Oct, 2019 1 commit
    • Josef Svenningsson's avatar
      Fix #15344: use fail when desugaring applicative-do · 6635a3f6
      Josef Svenningsson authored
      Applicative-do has a bug where it fails to use the monadic fail method
      when desugaring patternmatches which can fail. See #15344.
      
      This patch fixes that problem. It required more rewiring than I had expected.
      Applicative-do happens mostly in the renamer; that's where decisions about
      scheduling are made. This schedule is then carried through the typechecker and
      into the desugarer which performs the actual translation. Fixing this bug
      required sending information about the fail method from the renamer, through
      the type checker and into the desugarer. Previously, the desugarer didn't
      have enough information to actually desugar pattern matches correctly.
      
      As a side effect, we also fix #16628, where GHC wouldn't catch missing
      MonadFail instances with -XApplicativeDo.
      6635a3f6
  4. 25 Sep, 2019 1 commit
    • Vladislav Zavialov's avatar
      Standalone kind signatures (#16794) · 0b5eede9
      Vladislav Zavialov authored
      Implements GHC Proposal #54: .../ghc-proposals/blob/master/proposals/0054-kind-signatures.rst
      
      With this patch, a type constructor can now be given an explicit
      standalone kind signature:
      
        {-# LANGUAGE StandaloneKindSignatures #-}
        type Functor :: (Type -> Type) -> Constraint
        class Functor f where
          fmap :: (a -> b) -> f a -> f b
      
      This is a replacement for CUSKs (complete user-specified
      kind signatures), which are now scheduled for deprecation.
      
      User-facing changes
      -------------------
      
      * A new extension flag has been added, -XStandaloneKindSignatures, which
        implies -XNoCUSKs.
      
      * There is a new syntactic construct, a standalone kind signature:
      
          type <name> :: <kind>
      
        Declarations of data types, classes, data families, type families, and
        type synonyms may be accompanied by a standalone kind signature.
      
      * A standalone kind signature enables polymorphic recursion in types,
        just like a function type signature enables polymorphic recursion in
        terms. This obviates the need for CUSKs.
      
      * TemplateHaskell AST has been extended with 'KiSigD' to represent
        standalone kind signatures.
      
      * GHCi :info command now prints the kind signature of type constructors:
      
          ghci> :info Functor
          type Functor :: (Type -> Type) -> Constraint
          ...
      
      Limitations
      -----------
      
      * 'forall'-bound type variables of a standalone kind signature do not
        scope over the declaration body, even if the -XScopedTypeVariables is
        enabled. See #16635 and #16734.
      
      * Wildcards are not allowed in standalone kind signatures, as partial
        signatures do not allow for polymorphic recursion.
      
      * Associated types may not be given an explicit standalone kind
        signature. Instead, they are assumed to have a CUSK if the parent class
        has a standalone kind signature and regardless of the -XCUSKs flag.
      
      * Standalone kind signatures do not support multiple names at the moment:
      
          type T1, T2 :: Type -> Type   -- rejected
          type T1 = Maybe
          type T2 = Either String
      
        See #16754.
      
      * Creative use of equality constraints in standalone kind signatures may
        lead to GHC panics:
      
          type C :: forall (a :: Type) -> a ~ Int => Constraint
          class C a where
            f :: C a => a -> Int
      
        See #16758.
      
      Implementation notes
      --------------------
      
      * The heart of this patch is the 'kcDeclHeader' function, which is used to
        kind-check a declaration header against its standalone kind signature.
        It does so in two rounds:
      
          1. check user-written binders
          2. instantiate invisible binders a la 'checkExpectedKind'
      
      * 'kcTyClGroup' now partitions declarations into declarations with a
        standalone kind signature or a CUSK (kinded_decls) and declarations
        without either (kindless_decls):
      
          * 'kinded_decls' are kind-checked with 'checkInitialKinds'
          * 'kindless_decls' are kind-checked with 'getInitialKinds'
      
      * DerivInfo has been extended with a new field:
      
          di_scoped_tvs :: ![(Name,TyVar)]
      
        These variables must be added to the context in case the deriving clause
        references tcTyConScopedTyVars. See #16731.
      0b5eede9
  5. 20 Sep, 2019 1 commit
  6. 13 Sep, 2019 2 commits
  7. 07 Aug, 2019 1 commit
  8. 09 Jul, 2019 1 commit
    • Ryan Scott's avatar
      Use an empty data type in TTG extension constructors (#15247) · 6a03d77b
      Ryan Scott authored
      To avoid having to `panic` any time a TTG extension constructor is
      consumed, this MR introduces an uninhabited 'NoExtCon' type and uses
      that in every extension constructor's type family instance where it
      is appropriate. This also introduces a 'noExtCon' function which
      eliminates a 'NoExtCon', much like 'Data.Void.absurd' eliminates
      a 'Void'.
      
      I also renamed the existing `NoExt` type to `NoExtField` to better
      distinguish it from `NoExtCon`. Unsurprisingly, there is a lot of
      code churn resulting from this.
      
      Bumps the Haddock submodule. Fixes #15247.
      6a03d77b
  9. 31 May, 2019 2 commits
  10. 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
  11. 03 May, 2019 1 commit
    • Vladislav Zavialov's avatar
      Pattern/expression ambiguity resolution · 52fc2719
      Vladislav Zavialov authored
      This patch removes 'EWildPat', 'EAsPat', 'EViewPat', and 'ELazyPat'
      from 'HsExpr' by using the ambiguity resolution system introduced
      earlier for the command/expression ambiguity.
      
      Problem: there are places in the grammar where we do not know whether we
      are parsing an expression or a pattern, for example:
      
      	do { Con a b <- x } -- 'Con a b' is a pattern
      	do { Con a b }      -- 'Con a b' is an expression
      
      Until we encounter binding syntax (<-) we don't know whether to parse
      'Con a b' as an expression or a pattern.
      
      The old solution was to parse as HsExpr always, and rejig later:
      
      	checkPattern :: LHsExpr GhcPs -> P (LPat GhcPs)
      
      This meant polluting 'HsExpr' with pattern-related constructors. In
      other words, limitations of the parser were affecting the AST, and all
      other code (the renamer, the typechecker) had to deal with these extra
      constructors.
      
      We fix this abstraction leak by parsing into an overloaded
      representation:
      
      	class DisambECP b where ...
      	newtype ECP = ECP { runECP_PV :: forall b. DisambECP b => PV (Located b) }
      
      See Note [Ambiguous syntactic categories] for details.
      
      Now the intricacies of parsing have no effect on the hsSyn AST when it
      comes to the expression/pattern ambiguity.
      52fc2719
  12. 09 Mar, 2019 1 commit
    • Simon Peyton Jones's avatar
      Stop inferring over-polymorphic kinds · 1f5cc9dc
      Simon Peyton Jones authored
      Before this patch GHC was trying to be too clever
      (Trac #16344); it succeeded in kind-checking this
      polymorphic-recursive declaration
      
          data T ka (a::ka) b
            = MkT (T Type           Int   Bool)
                  (T (Type -> Type) Maybe Bool)
      
      As Note [No polymorphic recursion] discusses, the "solution" was
      horribly fragile.  So this patch deletes the key lines in
      TcHsType, and a wodge of supporting stuff in the renamer.
      
      There were two regressions, both the same: a closed type family
      decl like this (T12785b) does not have a CUSK:
        type family Payload (n :: Peano) (s :: HTree n x) where
          Payload Z (Point a) = a
          Payload (S n) (a `Branch` stru) = a
      
      To kind-check the equations we need a dependent kind for
      Payload, and we don't get that any more.  Solution: make it
      a CUSK by giving the result kind -- probably a good thing anyway.
      
      The other case (T12442) was very similar: a close type family
      declaration without a CUSK.
      1f5cc9dc
  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. 24 Feb, 2019 2 commits
    • Vladislav Zavialov's avatar
      Expression/command ambiguity resolution · e61f6e35
      Vladislav Zavialov authored
      This patch removes 'HsArrApp' and 'HsArrForm' from 'HsExpr' by
      introducing a new ambiguity resolution system in the parser.
      
      Problem: there are places in the grammar where we do not know whether we
      are parsing an expression or a command:
      
      	proc x -> do { (stuff) -< x }   -- 'stuff' is an expression
      	proc x -> do { (stuff) }        -- 'stuff' is a command
      
      Until we encounter arrow syntax (-<) we don't know whether to parse
      'stuff' as an expression or a command.
      
      The old solution was to parse as HsExpr always, and rejig later:
      
      	checkCommand :: LHsExpr GhcPs -> P (LHsCmd GhcPs)
      
      This meant polluting 'HsExpr' with command-related constructors. In
      other words, limitations of the parser were affecting the AST, and
      all other code (the renamer, the typechecker) had to deal with these
      extra constructors by panicking.
      
      We fix this abstraction leak by parsing into an intermediate
      representation, 'ExpCmd':
      
      	data ExpCmdG b where
      	  ExpG :: ExpCmdG HsExpr
      	  CmdG :: ExpCmdG HsCmd
      
      	type ExpCmd = forall b. ExpCmdG b -> PV (Located (b GhcPs))
      
      	checkExp :: ExpCmd -> PV (LHsExpr GhcPs)
      	checkCmd :: ExpCmd -> PV (LHsCmd GhcPs)
      	checkExp f = f ExpG  -- interpret as an expression
      	checkCmd f = f CmdG  -- interpret as a command
      
      See Note [Ambiguous syntactic categories] for details.
      
      Now the intricacies of parsing have no effect on the hsSyn AST when it
      comes to the expression/command ambiguity.
      
      Future work: apply the same principles to the expression/pattern
      ambiguity.
      e61f6e35
    • 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
  15. 16 Feb, 2019 1 commit
  16. 08 Feb, 2019 1 commit
    • Alan Zimmerman's avatar
      API Annotations: AnnAt disconnected for TYPEAPP · cbfc9fca
      Alan Zimmerman authored
      For the code
      
          type family F1 (a :: k) (f :: k -> Type) :: Type where
            F1 @Peano a f = T @Peano f a
      
      the API annotation for the first @ is not attached to a SourceSpan in
      the ParsedSource
      
      Closes #16236
      cbfc9fca
  17. 30 Jan, 2019 4 commits
    • Alec Theriault's avatar
      Include type info for only some exprs in HIE files · 5ed48d25
      Alec Theriault authored
      This commit relinquishes some some type information in `.hie` files in
      exchange for better performance. See #16233 for more on this.
      
      Using `.hie` files to generate hyperlinked sources is a crucial milestone
      towards Hi Haddock (the initiative to move Haddock to work over `.hi`
      files and embed docstrings in those). Unfortunately, even after much
      optimization on the Haddock side, the `.hie` based solution is still
      considerably slower and more memory hungry than the existing implementation
      - and the @.hie@ code is to blame.
      
      This changes `.hie` file generation to track type information for only
      a limited subset of expressions (specifically, those that might eventually
      turn into hyperlinks in the Haddock's hyperlinker backend).
      5ed48d25
    • Alec Theriault's avatar
      Use `NameEnv Id` instead of `Map Name Id` · 6fa38663
      Alec Theriault authored
      This is more consistent with the rest of the GHC codebase.
      6fa38663
    • Ben Gamari's avatar
      Revert "Batch merge" · 172a5933
      Ben Gamari authored
      This reverts commit 76c8fd67.
      172a5933
    • Ben Gamari's avatar
      Batch merge · 76c8fd67
      Ben Gamari authored
      76c8fd67
  18. 23 Jan, 2019 1 commit
  19. 11 Jan, 2019 1 commit
  20. 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
  21. 11 Dec, 2018 1 commit