1. 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
  2. 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
  3. 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
  4. 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
  5. 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
  6. 17 Nov, 2015 1 commit
  7. 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
  8. 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
  9. 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
  10. 07 Nov, 2015 1 commit
  11. 01 Nov, 2015 2 commits
  12. 30 Oct, 2015 1 commit
  13. 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
  14. 27 Oct, 2015 1 commit
  15. 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
  16. 08 Oct, 2015 2 commits
  17. 03 Sep, 2015 1 commit
  18. 10 Aug, 2015 1 commit
  19. 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
  20. 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
  21. 27 Jul, 2015 1 commit
    • Adam Sandberg Eriksson's avatar
      Implementation of StrictData language extension · f842ad6c
      Adam Sandberg Eriksson authored
      This implements the `StrictData` language extension, which lets the
      programmer default to strict data fields in datatype declarations on a
      per-module basis.
      
      Specification and motivation can be found at
      https://ghc.haskell.org/trac/ghc/wiki/StrictPragma
      
      This includes a tricky parser change due to conflicts regarding `~` in
      the type level syntax: all ~'s are parsed as strictness annotations (see
      `strict_mark` in Parser.y) and then turned into equality constraints at
      the appropriate places using `RdrHsSyn.splitTilde`.
      
      Updates haddock submodule.
      
      Test Plan: Validate through Harbormaster.
      
      Reviewers: goldfire, austin, hvr, simonpj, tibbe, bgamari
      
      Reviewed By: simonpj, tibbe, bgamari
      
      Subscribers: lelf, simonpj, alanz, goldfire, thomie, bgamari, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1033
      
      GHC Trac Issues: #8347
      f842ad6c
  22. 23 Jul, 2015 1 commit
  23. 04 Jul, 2015 2 commits
  24. 03 Jul, 2015 2 commits
    • Matthew Pickering's avatar
      Remove redundant parser entry point · e4bf4bf0
      Matthew Pickering authored
      `parseFullStmt` and `parseStatement` exposed the same parser entry
      point.
      
      Reviewers: austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: gibiansky, alanz, thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1014
      e4bf4bf0
    • Matthew Pickering's avatar
      Remove unnecessary OrdList from decl parser. · f07b7a87
      Matthew Pickering authored
      Each production produced a singleton list.
      
      Similar treatment is applied to the decl_cls parser.
      
      This changes the type of the parseDeclaration entry point to
      
      `parseDeclaration :: P (LHsDecl RdrName)`
      
      and
      
      `parseTypeSignature :: P (LHsDecl RdrName)`
      
      which is in line with the other parser entry points.
      
      This patch also updates the conflict commentary.  There were 4 reduce/reduce
      conflicts introduced by `ffc21506` which
      refactored tuple constraints.
      
      Reviewers: austin
      
      Reviewed By: austin
      
      Subscribers: thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1007
      f07b7a87
  25. 21 Jun, 2015 1 commit
  26. 18 Jun, 2015 1 commit
    • Alan Zimmerman's avatar
      Parser: commas_tup_tail duplicate SrcSpan on "Missing" value · 72b21c39
      Alan Zimmerman authored
      Summary:
      Parsing
      
          {-# LANGUAGE TupleSections #-}
      
          baz = (1, "hello", 6.5,,) 'a' (Just ())
      
      Results in the following AST fragment
      
          (L tests/examples/Tuple.hs:3:7-25
             (ExplicitTuple
                [ L tests/examples/Tuple.hs:3:8
                    (Present
                       (L tests/examples/Tuple.hs:3:8
                          (HsOverLit
                             (OverLit
                                (HsIntegral [ '1' ] 1)
                                PlaceHolder
                                (HsLit
                                   (HsString
                                      []
                                      {abstract:FastString}))
                                PlaceHolder))))
                , L tests/examples/Tuple.hs:3:11-17
                    (Present
                       (L tests/examples/Tuple.hs:3:11-17
                          (HsLit
                             (HsString
                                [ '"'
                                , 'h'
                                , 'e'
                                , 'l'
                                , 'l'
                                , 'o'
                                , '"'
                                ]
                                {abstract:FastString}))))
                , L tests/examples/Tuple.hs:3:20-22
                    (Present
                       (L tests/examples/Tuple.hs:3:20-22
                          (HsOverLit
                             (OverLit
                                (HsFractional
                                   (FL
                                      [ '6' , '.' , '5' ]
                                      (:% 13 2)))
                                PlaceHolder
                                (HsLit
                                   (HsString
                                      []
                                      {abstract:FastString}))
                                PlaceHolder))))
                , L tests/examples/Tuple.hs:3:24
                    (Missing PlaceHolder)
                , L tests/examples/Tuple.hs:3:24
                    (Missing PlaceHolder)
                ]
      
      The final `Missing PlaceHolder` has a duplicated `SrcSpan`
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, bgamari, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D995
      
      GHC Trac Issues: #10537
      72b21c39
  27. 15 Jun, 2015 1 commit
  28. 09 Jun, 2015 1 commit
    • thomasw's avatar
      Refactor wild card renaming · 058af6c9
      thomasw authored
      Summary:
      Refactor wild card error reporting
      
      * Merge `HsWildcardTy` and `HsNamedWildcardTy` into one constructor
        `HsWildCardTy` with as field the new type `HsWildCardInfo`, which has two
        constructors: `AnonWildCard` and `NamedWildCard`.
      
      * All partial type checks are removed from `RdrHsSyn.hs` and are now done
        during renaming in order to report better error messages. When wild cards
        are allowed in a type, the new function `rnLHsTypeWithWildCards` (or
        `rnHsSigTypeWithWildCards`) should be used. This will bring the named wild
        cards into scope before renaming them. When this is not done, renaming will
        trigger "Unexpected wild card..." errors.
      
        Unfortunately, this has to be done separately for anonymous wild cards
        because they are given a fresh name during renaming, so they will not cause
        an out-of-scope error. They are handled in `tc_hs_type`, as a special case
        of a lookup that fails.
      
        The previous opt-out approach is replaced with an opt-in approach. No more
        panics because of forgotten checks!
      
      * `[t| _ |]` isn't caught by the above two checks, so it is currently handled
        by a special case. The error message (generated in the `DsM` monad) doesn't
        provide as much context information as the other cases.
      
      * Instead of three (!) functions that walk `HsType`, there is now only one
        pure function called `collectWildCards`.
      
      * Alternative approach: catch all unwanted wild cards in `rnHsTyKi` by looking
        at the `HsDocContext`. This will reduce the number of places to catch
        unwanted wild cards form three to one, and make the error messages more
        uniform, albeit less informative, as the error context for renaming is not
        as informative as the one for type checking. A new constructor of
        `HsDocContext` will be required for pattern synonyms signatures.
      
        Small problem: currently type-class type signatures can't be distinguished
        from type signatures using the `HsDocContext`.
      
      This requires an update to the Haddock submodule.
      
      Test Plan: validate
      
      Reviewers: goldfire, simonpj, austin
      
      Reviewed By: simonpj
      
      Subscribers: bgamari, thomie, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D613
      
      GHC Trac Issues: #10098
      058af6c9
  29. 01 Jun, 2015 1 commit
    • Alan Zimmerman's avatar
      ApiAnnotations : strings in warnings do not return SourceText · e6191d1c
      Alan Zimmerman authored
      Summary:
      The strings used in a WARNING pragma are captured via
      
          strings :: { Located ([AddAnn],[Located FastString]) }
              : STRING { sL1 $1 ([],[L (gl $1) (getSTRING $1)]) }
          ..
      
      The STRING token has a method getSTRINGs that returns the original
      source text for a string.
      
      A warning of the form
      
          {-# WARNING Logic
                    , mkSolver
                    , mkSimpleSolver
                    , mkSolverForLogic
                    , solverSetParams
                    , solverPush
                    , solverPop
                    , solverReset
                    , solverGetNumScopes
                    , solverAssertCnstr
                    , solverAssertAndTrack
                    , solverCheck
                    , solverCheckAndGetModel
                    , solverGetReasonUnknown
                    "New Z3 API support is still incomplete and fragile: \
                    \you may experience segmentation faults!"
            #-}
      
      returns the concatenated warning string rather than the original source.
      
      This patch now deals with all remaining instances of getSTRING to bring
      in a SourceText for each.
      
      This updates the haddock submodule as well, for the AST change.
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin, goldfire
      
      Reviewed By: austin
      
      Subscribers: bgamari, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D907
      
      GHC Trac Issues: #10313
      e6191d1c
  30. 27 May, 2015 1 commit
    • Alan Zimmerman's avatar
      ApiAnnotations tweaks · c5911479
      Alan Zimmerman authored
      Summary:
      A collection of minor updates for the API Annotations.
      
      1. The annotations for the implicity parameter is disconnected in the
         following
      
          type MPI = ?mpi_secret :: MPISecret
      
      2. In the following, the annotation for one of the commas is disconeected.
      
          mkPoli = mkBila . map ((,,(),,()) <$> P.base <*> P.pos <*> P.form)
      
      3. In the following, the annotation for the parens becomes disconnected
      
          data MaybeDefault v where
              SetTo :: forall v . ( Eq v, Show v ) => !v -> MaybeDefault v
              SetTo4 :: forall v a. (( Eq v, Show v ) => v -> MaybeDefault v
                                                      -> a -> MaybeDefault [a])
      
      Test Plan: ./validate
      
      Reviewers: hvr, austin
      
      Reviewed By: austin
      
      Subscribers: bgamari, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D901
      
      GHC Trac Issues: #10399
      c5911479