1. 07 Jan, 2016 1 commit
  2. 02 Jan, 2016 1 commit
    • Alan Zimmerman's avatar
      AnnDotDot missing for Pattern Synonym export · f5ad1f03
      Alan Zimmerman authored
      For the following code fragment
      
          {-# LANGUAGE PatternSynonyms #-}
      
          module ExportSyntax ( A(.., NoA), Q(F,..), G(T,..,U)) where
      
      The second and third .. are missing AnnDotdot annotations.
      
      Closes #11332
      f5ad1f03
  3. 01 Jan, 2016 1 commit
    • Alan Zimmerman's avatar
      API Annotations: AnnTilde missing · 0b8dc7d4
      Alan Zimmerman authored
      In T10689a.hs, the fragment
      
          data instance Sing (z :: [a])
            = z ~ '[] =>
              SNil
            | forall (m :: a)
                     (n :: [a]). z ~ (:) m n =>
              SCons (Sing m) (Sing n)
      
      ends up with the AnnTilde annotations for the two tildes not attached to
      the final AST.
      
      This patch moves the AnnTilde to the right place.
      
      Closes #11321
      0b8dc7d4
  4. 30 Dec, 2015 1 commit
  5. 24 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Visible type application · 2db18b81
      eir@cis.upenn.edu authored
      This re-working of the typechecker algorithm is based on
      the paper "Visible type application", by Richard Eisenberg,
      Stephanie Weirich, and Hamidhasan Ahmed, to be published at
      ESOP'16.
      
      This patch introduces -XTypeApplications, which allows users
      to say, for example `id @Int`, which has type `Int -> Int`. See
      the changes to the user manual for details.
      
      This patch addresses tickets #10619, #5296, #10589.
      2db18b81
  6. 22 Dec, 2015 5 commits
    • Alan Zimmerman's avatar
      APIAnnotations:AnnComma in wrong place in qcnames1 · 721d56d5
      Alan Zimmerman authored
      The list is reversed when it is used, so the comma must be added to the
      item at the front of it, to be following it when used.
      721d56d5
    • Alan Zimmerman's avatar
      Localize API Annotation in LInjectivtyAnn · 7966eea9
      Alan Zimmerman authored
      The injectivity_cond production in Parser.y returns the annotation for
      the '->' to the calling production, rather than applying it directly.
      
      Rather apply it directly, so LInjectivityAnn can be rendered as a unit
      from the API Annotations.
      7966eea9
    • Simon Peyton Jones's avatar
      Fix typechecking for pattern synonym signatures · f40e122b
      Simon Peyton Jones authored
      Various tickets have revealed bad shortcomings in the typechecking of
      pattern type synonyms.  Discussed a lot in (the latter part of)
      Trac #11224.
      
      This patch fixes the most complex issues:
      
      - Both parser and renamer now treat pattern synonyms as an
        ordinary LHsSigType.  Nothing special.  Hooray.
      
      - tcPatSynSig (now in TcPatSyn) typechecks the signature, and
        decomposes it into its pieces.
        See Note [Pattern synonym signatures]
      
      - tcCheckPatSyn has had a lot of refactoring.
        See Note [Checking against a pattern signature]
      
      The result is a lot tidier and more comprehensible.
      Plus, it actually works!
      
      NB: this patch doesn't actually address the precise
          target of #11224, namely "inlining pattern synonym
          does not preserve semantics".  That's an unrelated
          bug, with a separate patch.
      
      ToDo: better documentation in the user manual
      
      Test Plan: Validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, mpickering, thomie, simonpj
      
      Differential Revision: https://phabricator.haskell.org/D1685
      
      GHC Trac Issues: #11224
      f40e122b
    • Alan Zimmerman's avatar
      Retain AnnTilde in splitTildeApps · b407bd77
      Alan Zimmerman authored
      splitTildeApps can introduce a new HsAppInfix for a tilde, with a fresh
      SrcSpan, disconnecting its existing AnnTilde API Annotation.
      
      A tilde needs AnnTilde to render properly, this patch adds a new one on
      the fresh SrcSpan
      b407bd77
    • Alan Zimmerman's avatar
      Make HsAppsType contents Located · ff923954
      Alan Zimmerman authored
      An HsAppInfix can carry a qconop/varop preceded by a SIMPLEQUOTE as a
      Located RdrName.
      
      In this case AnnSimpleQuote is attached to the Located HsAppType.
      
          | SIMPLEQUOTE qconop            {% ams (sLL $1 $> $ HsAppInfix $2)
                                                 [mj AnnSimpleQuote $1] }
          | SIMPLEQUOTE varop             {% ams (sLL $1 $> $ HsAppInfix $2)
                                                 [mj AnnSimpleQuote $1] }
      
      This patch changes
      
          data HsType name
            ...
            | HsAppsTy [HsAppType name]
      
      to
      
          data HsType name
            ...
            | HsAppsTy [LHsAppType name]
      
      so that the annotation is not discarded when it reaches the ParsedSource
      ff923954
  7. 21 Dec, 2015 2 commits
    • msosn's avatar
      Warn about unused type variables in type families · eb7796f1
      msosn authored
      The warnings are enabled with the flag -fwarn-unused-matches, the same
      one that enables warnings on the term level.
      
      Identifiers starting with an underscore are now always parsed as type
      variables.  When the NamedWildCards extension is enabled, the renamer
      replaces those variables with named wildcards.
      
      An additional NameSet nwcs is added to LocalRdrEnv. It's used to keep
      names of the type variables that should be replaced with wildcards.
      
      While renaming HsForAllTy, when a name is explicitly bound it is removed
      from the nwcs NameSet. As a result, the renamer doesn't replace them in
      the quantifier body. (Trac #11098)
      
      Fixes #10982, #11098
      
      Reviewers: alanz, bgamari, hvr, austin, jstolarek
      
      Reviewed By: jstolarek
      
      Subscribers: goldfire, mpickering, RyanGlScott, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1576
      
      GHC Trac Issues: #10982
      eb7796f1
    • Alan Zimmerman's avatar
      Add Location to RdrName in FieldOcc · d8ed20c8
      Alan Zimmerman authored
      Summary:
      Post #11019, there have been some new instances of RdrName that are not
      located, in particular
      
      ```#!hs
      data FieldOcc name = FieldOcc { rdrNameFieldOcc  :: RdrName
                                    , selectorFieldOcc :: PostRn name name
                                    }
      
      data AmbiguousFieldOcc name
        = Unambiguous RdrName (PostRn name name)
        | Ambiguous   RdrName (PostTc name name)
        deriving (Typeable)
      ```
      Add locations to them
      
      Updates haddock submodule to match
      
      Test Plan: ./validate
      
      Reviewers: goldfire, hvr, bgamari, austin
      
      Reviewed By: hvr
      
      Subscribers: hvr, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1670
      
      GHC Trac Issues: #11258
      d8ed20c8
  8. 15 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Expose enabled language extensions to TH · c1e25536
      Ben Gamari authored
      This exposes `template-haskell` functions for querying the language
      extensions which are enabled when compiling a module,
      
      - an `isExtEnabled` function to check whether an extension is enabled
      - an `extsEnabled` function to obtain a full list of enabled extensions
      
      To avoid code duplication this adds a `GHC.LanguageExtensions` module to
      `ghc-boot` and moves `DynFlags.ExtensionFlag` into it. A happy
      consequence of this is that the ungainly `DynFlags` lost around 500
      lines. Moreover, flags corresponding to language extensions are now
      clearly distinguished from other flags due to the `LangExt.*` prefix.
      
      Updates haddock submodule.
      
      This fixes #10820.
      
      Test Plan: validate
      
      Reviewers: austin, spinda, hvr, goldfire, alanz
      
      Reviewed By: goldfire
      
      Subscribers: mpickering, RyanGlScott, hvr, simonpj, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1200
      
      GHC Trac Issues: #10820
      c1e25536
  9. 11 Dec, 2015 1 commit
    • eir@cis.upenn.edu's avatar
      Add kind equalities to GHC. · 67465497
      eir@cis.upenn.edu authored
      This implements the ideas originally put forward in
      "System FC with Explicit Kind Equality" (ICFP'13).
      
      There are several noteworthy changes with this patch:
       * We now have casts in types. These change the kind
         of a type. See new constructor `CastTy`.
      
       * All types and all constructors can be promoted.
         This includes GADT constructors. GADT pattern matches
         take place in type family equations. In Core,
         types can now be applied to coercions via the
         `CoercionTy` constructor.
      
       * Coercions can now be heterogeneous, relating types
         of different kinds. A coercion proving `t1 :: k1 ~ t2 :: k2`
         proves both that `t1` and `t2` are the same and also that
         `k1` and `k2` are the same.
      
       * The `Coercion` type has been significantly enhanced.
         The documentation in `docs/core-spec/core-spec.pdf` reflects
         the new reality.
      
       * The type of `*` is now `*`. No more `BOX`.
      
       * Users can write explicit kind variables in their code,
         anywhere they can write type variables. For backward compatibility,
         automatic inference of kind-variable binding is still permitted.
      
       * The new extension `TypeInType` turns on the new user-facing
         features.
      
       * Type families and synonyms are now promoted to kinds. This causes
         trouble with parsing `*`, leading to the somewhat awkward new
         `HsAppsTy` constructor for `HsType`. This is dispatched with in
         the renamer, where the kind `*` can be told apart from a
         type-level multiplication operator. Without `-XTypeInType` the
         old behavior persists. With `-XTypeInType`, you need to import
         `Data.Kind` to get `*`, also known as `Type`.
      
       * The kind-checking algorithms in TcHsType have been significantly
         rewritten to allow for enhanced kinds.
      
       * The new features are still quite experimental and may be in flux.
      
       * TODO: Several open tickets: #11195, #11196, #11197, #11198, #11203.
      
       * TODO: Update user manual.
      
      Tickets addressed: #9017, #9173, #7961, #10524, #8566, #11142.
      Updates Haddock submodule.
      67465497
  10. 07 Dec, 2015 1 commit
    • Alan Zimmerman's avatar
      Refactor ConDecl · 51a5e68d
      Alan Zimmerman authored
      The ConDecl type in HsDecls is an uneasy compromise. For the most part,
      HsSyn directly reflects the syntax written by the programmer; and that
      gives just the right "pegs" on which to hang Alan's API annotations. But
      ConDecl doesn't properly reflect the syntax of Haskell-98 and GADT-style
      data type declarations.
      
      To be concrete, here's a draft new data type
      
      ```lang=hs
      data ConDecl name
        | ConDeclGADT
            { con_names   :: [Located name]
            , con_type    :: LHsSigType name  -- The type after the ‘::’
            , con_doc     :: Maybe LHsDocString }
      
        | ConDeclH98
            { con_name    :: Located name
      
            , con_qvars     :: Maybe (LHsQTyVars name)
              -- User-written forall (if any), and its implicit
              -- kind variables
              -- Non-Nothing needs -XExistentialQuantification
      
            , con_cxt       :: Maybe (LHsContext name)
              -- ^ User-written context (if any)
      
            , con_details   :: HsConDeclDetails name
                -- ^ Arguments
      
            , con_doc       :: Maybe LHsDocString
                -- ^ A possible Haddock comment.
            } deriving (Typeable)
      ```
      
      Note that
      
          For GADTs, just keep a type. That's what the user writes.
          NB:HsType can represent records on the LHS of an arrow:
      
            { x:Int,y:Bool} -> T
      
          con_qvars and con_cxt are both Maybe because they are both
          optional (the forall and the context of an existential data type
      
          For ConDeclGADT the type variables of the data type do not scope
          over the con_type; whereas for ConDeclH98 they do scope over con_cxt
          and con_details.
      
      Updates haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: simonpj, erikd, hvr, goldfire, austin, bgamari
      
      Subscribers: erikd, goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1558
      
      GHC Trac Issues: #11028
      51a5e68d
  11. 01 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor treatment of wildcards · 1e041b73
      Simon Peyton Jones authored
      This patch began as a modest refactoring of HsType and friends, to
      clarify and tidy up exactly where quantification takes place in types.
      Although initially driven by making the implementation of wildcards more
      tidy (and fixing a number of bugs), I gradually got drawn into a pretty
      big process, which I've been doing on and off for quite a long time.
      
      There is one compiler performance regression as a result of all
      this, in perf/compiler/T3064.  I still need to look into that.
      
      * The principal driving change is described in Note [HsType binders]
        in HsType.  Well worth reading!
      
      * Those data type changes drive almost everything else.  In particular
        we now statically know where
      
             (a) implicit quantification only (LHsSigType),
                 e.g. in instance declaratios and SPECIALISE signatures
      
             (b) implicit quantification and wildcards (LHsSigWcType)
                 can appear, e.g. in function type signatures
      
      * As part of this change, HsForAllTy is (a) simplified (no wildcards)
        and (b) split into HsForAllTy and HsQualTy.  The two contructors
        appear when and only when the correponding user-level construct
        appears.  Again see Note [HsType binders].
      
        HsExplicitFlag disappears altogether.
      
      * Other simplifications
      
           - ExprWithTySig no longer needs an ExprWithTySigOut variant
      
           - TypeSig no longer needs a PostRn name [name] field
             for wildcards
      
           - PatSynSig records a LHsSigType rather than the decomposed
             pieces
      
           - The mysterious 'GenericSig' is now 'ClassOpSig'
      
      * Renamed LHsTyVarBndrs to LHsQTyVars
      
      * There are some uninteresting knock-on changes in Haddock,
        because of the HsSyn changes
      
      I also did a bunch of loosely-related changes:
      
      * We already had type synonyms CoercionN/CoercionR for nominal and
        representational coercions.  I've added similar treatment for
      
            TcCoercionN/TcCoercionR
      
            mkWpCastN/mkWpCastN
      
        All just type synonyms but jolly useful.
      
      * I record-ised ForeignImport and ForeignExport
      
      * I improved the (poor) fix to Trac #10896, by making
        TcTyClsDecls.checkValidTyCl recover from errors, but adding a
        harmless, abstract TyCon to the envt if so.
      
      * I did some significant refactoring in RnEnv.lookupSubBndrOcc,
        for reasons that I have (embarrassingly) now totally forgotten.
        It had to do with something to do with import and export
      
      Updates haddock submodule.
      1e041b73
  12. 22 Nov, 2015 2 commits
    • Alan Zimmerman's avatar
      ApiAnnotations: Make all RdrName occurences Located · 3df9563e
      Alan Zimmerman authored
      At the moment the API Annotations can only be used on the ParsedSource,
      as there are changes made to the RenamedSource that prevent it from
      being used to round trip source code.
      
      It is possible to build a map from every Located Name in the
      RenamedSource from its location to the Name, which can then be used when
      resolved names are required when changing the ParsedSource.
      
      However, there are instances where the identifier is not located,
      specifically
      
        (GHC.VarPat name)
        (GHC.HsVar name)
        (GHC.UserTyVar name)
        (GHC.HsTyVar name)
      
      Replace each of the name types above with (Located name)
      
      Updates the haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1512
      
      GHC Trac Issues: #11019
      3df9563e
    • Alan Zimmerman's avatar
      Add comment to Parser.y re extra API Annotation · 638fde50
      Alan Zimmerman authored
      Document extra AnnRarrow annotation on a HsFunTy
      638fde50
  13. 17 Nov, 2015 1 commit
  14. 16 Nov, 2015 2 commits
    • Alan Zimmerman's avatar
      ApiAnnotations : ITopenExpQuote needs SourceText · ee914828
      Alan Zimmerman authored
      Summary:
      In the lexer, ITopenExpQuote can be recognised for '[e|' or '[|'.
      
      The token definition needs to capture the original SourceText, and pass
      it through to ExpBr, which also needs a SrcText field.
      
      It is easier to simply add a flag  to the token identifying the variant
      and to generate a different AnnKeywordId based on this.
      
      Test Plan: ./validate
      
      Reviewers: mpickering, bgamari, austin
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1479
      
      GHC Trac Issues: #10276
      ee914828
    • Alan Zimmerman's avatar
      ApiAnnotations: Add SourceText for unicode tokens · fe95463b
      Alan Zimmerman authored
      Summary:
      At the moment there is no way to tell if a given token used its unicode
      variant or its normal one, except to look at the length of the token.
      
      This fails for the unicode '*'.
      
      Expose the original source text for unicode variants so that API
      Annotations can capture them specifically.
      
      Test Plan: ./validate
      
      Reviewers: mpickering, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1473
      
      GHC Trac Issues: #11018
      fe95463b
  15. 13 Nov, 2015 1 commit
    • Alan Zimmerman's avatar
      APIAnnotations:add Locations in hsSyn for layout · 2290c8bd
      Alan Zimmerman authored
      Summary:
      At the moment ghc-exactprint, which uses the GHC API Annotations to
      provide a framework for roundtripping Haskell source code with optional
      AST edits, has to implement a horrible workaround to manage the points
      where layout needs to be captured.
      
      These are
      
          MatchGroup
          HsDo
          HsCmdDo
          HsLet
          LetStmt
          HsCmdLet
          GRHSs
      
      To provide a more natural representation, the contents subject to layout
      rules need to be wrapped in a SrcSpan.
      
      This commit does this.
      
      Trac ticket #10250
      
      Test Plan: ./validate
      
      Reviewers: hvr, goldfire, bgamari, austin, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1370
      
      GHC Trac Issues: #10250
      2290c8bd
  16. 11 Nov, 2015 3 commits
    • Jan Stolarek's avatar
      mkGadtDecl no longer in P monad · afbd30b6
      Jan Stolarek authored
      Since `mkGadtDecl` does not use any of the functions specific to the `P`
      monad we can extract it from that monad and reuse in other parts of the
      compiler.
      
      Test Plan: ./validate
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1461
      afbd30b6
    • Alan Zimmerman's avatar
      Remove fun_infix from Funbind, as it is now in Match · f0f9365f
      Alan Zimmerman authored
      One of the changes D538 introduced is to add `m_fun_id_infix` to `Match`
      
      ```lang=hs
      data Match id body
        = Match {
              m_fun_id_infix :: (Maybe (Located id,Bool)),
                -- fun_id and fun_infix for functions with multiple equations
                -- only present for a RdrName. See note [fun_id in Match]
              m_pats :: [LPat id], -- The patterns
              m_type :: (Maybe (LHsType id)),
                                       -- A type signature for the result of the match
                                       -- Nothing after typechecking
              m_grhss :: (GRHSs id body)
        } deriving (Typeable)
      ```
      
      This was done to track the individual locations and fixity of the
      `fun_id` for each of the defining equations for a function when there
      are more than one.
      
      For example, the function `(&&&)` is defined with some prefix and some
      infix equations below.
      
      ```lang=hs
          (&&&  ) [] [] =  []
          xs    &&&   [] =  xs
          (  &&&  ) [] ys =  ys
      ```
      
      This means that the fun_infix is now superfluous in the `FunBind`. This
      has not been removed as a potentially risky change just before 7.10 RC2,
      and so must be done after.
      
      This ticket captures that task, which includes processing these fields
      through the renamer and beyond.
      
      Ticket #9988 introduced these fields into `Match` through renaming, this
      ticket it to continue through type checking and then remove it from
      `FunBind` completely.
      
      The split happened so that #9988 could land in 7.10
      
      Trac ticket : #10061
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1285
      
      GHC Trac Issues: #10061
      f0f9365f
    • Matthew Pickering's avatar
      Associate pattern synonyms with types in module exports · 96621b1b
      Matthew Pickering authored
      This patch implements #10653.
      
      It adds the ability to bundle pattern synonyms with type constructors in
      export lists so that users can treat pattern synonyms more like data
      constructors.
      
      Updates haddock submodule.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, gridaphobe, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1258
      
      GHC Trac Issues: #10653
      96621b1b
  17. 07 Nov, 2015 1 commit
  18. 01 Nov, 2015 2 commits
  19. 30 Oct, 2015 1 commit
  20. 29 Oct, 2015 1 commit
    • Matthew Pickering's avatar
      Record pattern synonyms · 2a74a64e
      Matthew Pickering authored
      This patch implements an extension to pattern synonyms which allows user
      to specify pattern synonyms using record syntax. Doing so generates
      appropriate selectors and update functions.
      
      === Interaction with Duplicate Record Fields ===
      
      The implementation given here isn't quite as general as it could be with
      respect to the recently-introduced `DuplicateRecordFields` extension.
      
      Consider the following module:
      
          {-# LANGUAGE DuplicateRecordFields #-}
          {-# LANGUAGE PatternSynonyms #-}
      
          module Main where
      
          pattern S{a, b} = (a, b)
          pattern T{a}    = Just a
      
          main = do
            print S{ a = "fst", b = "snd" }
            print T{ a = "a" }
      
      In principle, this ought to work, because there is no ambiguity. But at
      the moment it leads to a "multiple declarations of a" error. The problem
      is that pattern synonym record selectors don't do the same name mangling
      as normal datatypes when DuplicateRecordFields is enabled. They could,
      but this would require some work to track the field label and selector
      name separately.
      
      In particular, we currently represent datatype selectors in the third
      component of AvailTC, but pattern synonym selectors are just represented
      as Avails (because they don't have a corresponding type constructor).
      Moreover, the GlobalRdrElt for a selector currently requires it to have
      a parent tycon.
      
      (example due to Adam Gundry)
      
      === Updating Explicitly Bidirectional Pattern Synonyms ===
      
      Consider the following
      
      ```
      pattern Silly{a} <- [a] where
        Silly a = [a, a]
      
      f1 = a [5] -- 5
      
      f2 = [5] {a = 6} -- currently [6,6]
      ```
      
      === Fixing Polymorphic Updates ===
      
      They were fixed by adding these two lines in `dsExpr`. This might break
      record updates but will be easy to fix.
      
      ```
      + ; let req_wrap = mkWpTyApps (mkTyVarTys univ_tvs)
      
      - , pat_wrap = idHsWrapper }
      +, pat_wrap = req_wrap }
      ```
      
      === Mixed selectors error ===
      
      Note [Mixed Record Field Updates]
      ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      
      Consider the following pattern synonym.
      
          data MyRec = MyRec { foo :: Int, qux :: String }
      
          pattern HisRec{f1, f2} = MyRec{foo = f1, qux=f2}
      
      This allows updates such as the following
      
          updater :: MyRec -> MyRec
          updater a = a {f1 = 1 }
      
      It would also make sense to allow the following update (which we
      reject).
      
          updater a = a {f1 = 1, qux = "two" } ==? MyRec 1 "two"
      
      This leads to confusing behaviour when the selectors in fact refer the
      same field.
      
          updater a = a {f1 = 1, foo = 2} ==? ???
      
      For this reason, we reject a mixture of pattern synonym and normal
      record selectors in the same update block. Although of course we still
      allow the following.
      
          updater a = (a {f1 = 1}) {foo = 2}
      
          > updater (MyRec 0 "str")
          MyRec 2 "str"
      2a74a64e
  21. 27 Oct, 2015 1 commit
  22. 16 Oct, 2015 1 commit
    • Adam Gundry's avatar
      Implement DuplicateRecordFields · b1884b0e
      Adam Gundry authored
      This implements DuplicateRecordFields, the first part of the
      OverloadedRecordFields extension, as described at
      https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields/DuplicateRecordFields
      
      This includes fairly wide-ranging changes in order to allow multiple
      records within the same module to use the same field names.  Note that
      it does *not* allow record selector functions to be used if they are
      ambiguous, and it does not have any form of type-based disambiguation
      for selectors (but it does for updates). Subsequent parts will make
      overloading selectors possible using orthogonal extensions, as
      described on the wiki pages.  This part touches quite a lot of the
      codebase, and requires changes to several GHC API datatypes in order
      to distinguish between field labels (which may be overloaded) and
      selector function names (which are always unique).
      
      The Haddock submodule has been adapted to compile with the GHC API
      changes, but it will need further work to properly support modules
      that use the DuplicateRecordFields extension.
      
      Test Plan: New tests added in testsuite/tests/overloadedrecflds; these
      will be extended once the other parts are implemented.
      
      Reviewers: goldfire, bgamari, simonpj, austin
      
      Subscribers: sjcjoosten, haggholm, mpickering, bgamari, tibbe, thomie,
      goldfire
      
      Differential Revision: https://phabricator.haskell.org/D761
      b1884b0e
  23. 08 Oct, 2015 2 commits
  24. 03 Sep, 2015 1 commit
  25. 10 Aug, 2015 1 commit
  26. 03 Aug, 2015 3 commits
    • skvadrik's avatar
      Removed deprecated syntax for GADT constuctors. · 30c981e1
      skvadrik authored
      Old syntax was deprecated 6 years ago in this commit
      432b9c93 by simonpj:"New syntax for
      GADT-style record declarations, and associated refactoring" discussed
      in Trac #3306.
      
      This patch removes 2 reduce/reduce conflicts in parser. Conflicting
      productions were:
      
      ```
          gadt_constr -> con_list '::' sigtype
          gadt_constr -> oqtycon '{' fielddecls '}' '::' sigtype
      ```
      
      Recursive inlining of `con_list` and `oqtycon` helped reveal the
      conflict:
      
      ```
          gadt_constr -> '(' CONSYM ')' '::' sigtype
          gadt_constr -> '(' CONSYM ')' '{' fielddecls '}' '::' sigtype
      ```
      
      between two types of GADT constructors (second form stands for
      deprecated syntax).
      
      Test Plan: `make fasttest`, one breakage TEST="records-fail" (parse
      error instead of typecheck error due to removal of deprecated syntax).
      Updated test.
      
      Reviewers: simonmar, bgamari, austin, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie, mpickering, trofi
      
      Differential Revision: https://phabricator.haskell.org/D1118
      
      GHC Trac Issues: #3306
      30c981e1
    • Gabor Greif's avatar
      Typos in comments [skip ci] · 7ec6ffc4
      Gabor Greif authored
      7ec6ffc4
    • skvadrik's avatar
      4 reduce/reduce parser conflicts resolved · 697079f1
      skvadrik authored
      As GHC documentation (section 7.4.4, Type operators) says:
      > "There is now some potential ambiguity in import and export lists;
      for example if you write import M( (+) ) do you mean the function (+)
      or the type constructor (+)? The default is the former, but with
      -XExplicitNamespaces (which is implied by -XExplicitTypeOperators) GHC
      allows you to specify the latter by preceding it with the keyword type"
      
      Turns out this ambiguity causes 4 of 6 reduce/reduce conflicts in GHC
      parser.  All 4 conflicts arise from a single production:
      
          qcname
              :  qvar
              |  oqtycon
      
      Recursive inlining of 'qvar' and 'oqtycon' helps reveal the faulty
      productions:
      
          qcname
              :
          ...
              | '(' QVARSYM ')'
              | '(' VARSYM ')'
              | '(' '*'    ')'
              | '(' '-'    ')'
      
      These productions can either be parsed as variable or type constructor,
      but variable constuctor is always preferred. My patch removes ambiguity
      while preserving the existing behaviour:
      
        - all unambigous productions are left as-is
        - ambigous productions for variable constuctors are left
        - ambigous productions for type constructors are removed (there's no
          way they could be triggered)
      
      Updated comment.
      
      Test Plan: Tested with 'make fasttest'
      
      Reviewers: austin, simonpj, trofi, bgamari, simonmar
      
      Reviewed By: trofi, bgamari, simonmar
      
      Subscribers: thomie, mpickering
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1111
      697079f1
  27. 02 Aug, 2015 1 commit
    • Alan Zimmerman's avatar
      Replace (SourceText,FastString) with StringLiteral data type · 15dd7007
      Alan Zimmerman authored
      Summary:
      Phab:D907 introduced SourceText for a number of data types, by replacing
      FastString with (SourceText,FastString). Since this has an Outputable
      instance, no warnings are generated when ppr is called on it, but
      unexpected output is generated. See Phab:D1096 for an example of this.
      
      Replace the (SourceText,FastString) tuples with a new data type,
      ```lang=hs
      data StringLiteral = StringLiteral SourceText FastString
      ```
      
      Update haddock submodule accordingly
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, rwbarton, trofi, bgamari
      
      Reviewed By: trofi, bgamari
      
      Subscribers: thomie, trofi, rwbarton, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1101
      
      GHC Trac Issues: #10692
      15dd7007