1. 18 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      (Another) minor refactoring of substitutions · b5292557
      Simon Peyton Jones authored
      No change in functionality here, but greater clarity:
      
      * In FamInstEnv.FlattenEnv, kill off the fi_in_scope field
        We are already maintaining an in-scope set in the fe_subst field,
        so it's silly do to it twice.
      
        (This isn't strictly connected to the rest of this patch, but
        the nomenclature changes below affect the same code, so I put
        them together.)
      
      * TyCoRep.extendTCVSubst used to take a TyVar or a CoVar and work
        out what to do, but in fact we almost always know which of the
        two we are doing.  So:
          - define extendTvSubst, extendCvSubst
          - and use them
      
      * Similar renamings in TyCoRep:
         - extendTCvSubstList        -->   extendTvSubstList
         - extendTCvSubstBinder      -->   extendTvSubstBinder
         - extendTCvSubstAndInScope  --> extendTvSubstAndInScope
      
      * Add Type.extendTvSubstWithClone, extendCvSubstWithClone
      
      * Similar nomenclature changes in Subst, SimplEnv, Specialise
      
      * Kill off TyCoRep.substTelescope (never used)
      b5292557
  2. 12 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve pretty-printing of HsWrappers · d0846243
      Simon Peyton Jones authored
      Reduces un-neede parens.
      
      Also -fprint-typechecker-elaboration now makes type applications
      and casts in expressions also appear.  (Previously those were
      confusingly controlled by -fprint-explicit-coercions.)
      d0846243
  3. 30 Jan, 2016 1 commit
    • niteria's avatar
      Add asserts to other substitution functions · bb956eb8
      niteria authored
      This adds asserts to `substTys`, `substCo` and `substCos` in
      the same spirit as already existing asserts on `substTy`, protecting
      every possible entry point to `subst_ty` and `subst_co`.
      
      I've replaced the violators with unchecked versions.
      
      Test Plan: ./validate --slow
      
      Reviewers: simonpj, goldfire, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1862
      
      GHC Trac Issues: #11371
      bb956eb8
  4. 27 Jan, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Refactor the typechecker to use ExpTypes. · 00cbbab3
      eir@cis.upenn.edu authored
      The idea here is described in [wiki:Typechecker]. Briefly,
      this refactor keeps solid track of "synthesis" mode vs
      "checking" in GHC's bidirectional type-checking algorithm.
      When in synthesis mode, the expected type is just an IORef
      to write to.
      
      In addition, this patch does a significant reworking of
      RebindableSyntax, allowing much more freedom in the types
      of the rebindable operators. For example, we can now have
      `negate :: Int -> Bool` and
      `(>>=) :: m a -> (forall x. a x -> m b) -> m b`. The magic
      is in tcSyntaxOp.
      
      This addresses tickets #11397, #11452, and #11458.
      
      Tests:
        typecheck/should_compile/{RebindHR,RebindNegate,T11397,T11458}
        th/T11452
      00cbbab3
  5. 19 Jan, 2016 1 commit
    • niteria's avatar
      Check InScopeSet in substTy and provide substTyUnchecked · 9d33adb6
      niteria authored
      This adds sanity checks to `substTy` that implement:
      
      > when calling substTy subst ty it should be the case that the in-scope
      > set in the substitution is a superset of
      > * The free vars of the range of the substitution
      > * The free vars of ty minus the domain of the substitution
      
      and replaces violators with unchecked version. The violators were found
      by running the GHC test suite.
      
      This ensures that I can work on this incrementally and that what I fix won't
      be undone by some other change.
      
      It also includes a couple of fixes that I've already done.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1792
      
      GHC Trac Issues: #11371
      9d33adb6
  6. 18 Jan, 2016 2 commits
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · b8abd852
      Jan Stolarek authored
      Summary:
      In the past the canonical way for constructing an SDoc string literal was the
      composition `ptext . sLit`.  But for some time now we have function `text` that
      does the same.  Plus it has some rules that optimize its runtime behaviour.
      This patch takes all uses of `ptext . sLit` in the compiler and replaces them
      with calls to `text`.  The main benefits of this patch are clener (shorter) code
      and less dependencies between module, because many modules now do not need to
      import `FastString`.  I don't expect any performance benefits - we mostly use
      SDocs to report errors and it seems there is little to be gained here.
      
      Test Plan: ./validate
      
      Reviewers: bgamari, austin, goldfire, hvr, alanz
      
      Subscribers: goldfire, thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1784
      b8abd852
    • Eric Seidel's avatar
      un-wire-in error, undefined, CallStack, and IP · a7b751db
      Eric Seidel authored
      I missed a crucial step in the wiring-in process of `CallStack` in D861,
      the bit where you actually wire-in the Name... This led to a nasty bug
      where GHC thought `CallStack` was not wired-in and tried to fingerprint
      it, which failed because the defining module was not loaded.
      
      But we don't need `CallStack` to be wired-in anymore since `error` and
      `undefined` no longer need to be wired-in. So we just remove them all.
      
      Updates haddock submodule.
      
      Test Plan: `./validate` and `make slowtest TEST=tc198`
      
      Reviewers: simonpj, goldfire, austin, hvr, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: goldfire, thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1739
      
      GHC Trac Issues: #11331
      a7b751db
  7. 16 Jan, 2016 1 commit
    • Alan Zimmerman's avatar
      Work SourceText in for all integer literals · 3a1babd6
      Alan Zimmerman authored
      Summary:
      Certain syntactic elements have integers in them, such as fixity
      specifications, SPECIALISE pragmas and so on.
      
      The lexer will accept mult-radix literals, with arbitrary leading zeros
      in these.
      
      Bring in a SourceText field to each affected AST element to capture the
      original literal text for use with API Annotations.
      
      Affected hsSyn elements are
      
      ```
           -- See note [Pragma source text]
           data Activation = NeverActive
                           | AlwaysActive
                           | ActiveBefore SourceText PhaseNum
                                -- Active only *strictly before* this phase
                           | ActiveAfter SourceText PhaseNum
                                 -- Active in this phase and later
                           deriving( Eq, Data, Typeable )
                                     -- Eq used in comparing rules in HsDecls
      
           data Fixity = Fixity SourceText Int FixityDirection
             -- Note [Pragma source text]
             deriving (Data, Typeable)
       ```
      
      and
      
      ```
            | HsTickPragma         -- A pragma introduced tick
               SourceText           -- Note [Pragma source text] in BasicTypes
               (StringLiteral,(Int,Int),(Int,Int))
                                                -- external span for this tick
               ((SourceText,SourceText),(SourceText,SourceText))
                  -- Source text for the four integers used in the span.
                  -- See note [Pragma source text] in BasicTypes
               (LHsExpr id)
      ```
      
      Updates haddock submodule
      
      Test Plan: ./validate
      
      Reviewers: goldfire, bgamari, austin
      
      Reviewed By: bgamari
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D1781
      
      GHC Trac Issues: #11430
      3a1babd6
  8. 15 Jan, 2016 1 commit
  9. 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
  10. 22 Dec, 2015 1 commit
    • 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
  11. 21 Dec, 2015 1 commit
    • 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
  12. 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
  13. 11 Dec, 2015 2 commits
    • 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
    • Adam Gundry's avatar
      Fix infix record field fixity (#11167 and #11173). · 6e56ac58
      Adam Gundry authored
      This extends D1585 with proper support for infix duplicate record
      fields.  In particular, it is now possible to declare record fields as
      infix in a module for which `DuplicateRecordFields` is enabled, fixity
      is looked up correctly and a readable (although unpleasant) error
      message is generated if multiple fields with different fixities are in
      scope.
      
      As a bonus, `DEPRECATED` and `WARNING` pragmas now work for
      duplicate record fields. The pragma applies to all fields with the
      given label.
      
      In addition, a couple of minor `DuplicateRecordFields` bugs, which were
      pinpointed by the `T11167_ambig` test case, are fixed by this patch:
      
        - Ambiguous infix fields can now be disambiguated by putting a type
          signature on the first argument
      
        - Polymorphic type constructor signatures (such as `ContT () IO a` in
          `T11167_ambig`) now work for disambiguation
      
      Parts of this patch are from D1585 authored by @KaneTW.
      
      Test Plan: New tests added.
      
      Reviewers: KaneTW, bgamari, austin
      
      Reviewed By: bgamari
      
      Subscribers: thomie, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1600
      
      GHC Trac Issues: #11167, #11173
      6e56ac58
  14. 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
  15. 22 Nov, 2015 1 commit
    • 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
  16. 18 Nov, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor HsExpr.RecordCon, RecordUpd · 07eb258d
      Simon Peyton Jones authored
      This follows Matthew's patch making pattern synoyms work
      with records.
      
      This patch
       - replaces the (PostTc id [FieldLabel]) field of
         RecordCon with (PostTc id ConLike)
      
       - record-ises both RecordCon and RecordUpd, which
         both have quite a lot of fields.
      
      No change in behaviour
      07eb258d
  17. 17 Nov, 2015 1 commit
  18. 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
  19. 07 Nov, 2015 1 commit
    • Matthew Pickering's avatar
      Remove PatSynBuilderId · 22080113
      Matthew Pickering authored
      Summary:
      It was only used to pass field labels between the typechecker and
      desugarer. Instead we add an extra field the RecordCon to carry this
      information.
      
      Reviewers: austin, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1443
      
      GHC Trac Issues: #11057
      22080113
  20. 30 Oct, 2015 2 commits
    • Adam Gundry's avatar
      Disambiguate record selectors by type signature · 0a163741
      Adam Gundry authored
      This makes DuplicateRecordFields more liberal in when it will
      accept ambiguous record selectors, making use of type information in a
      similar way to updates. See Note [Disambiguating record fields] for more
      details. I've also refactored how record updates are disambiguated.
      
      Test Plan: New and amended tests in overloadedrecflds
      
      Reviewers: simonpj, goldfire, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1391
      0a163741
    • Simon Peyton Jones's avatar
      Record usage information using GlobalRdrElt · 3e94842d
      Simon Peyton Jones authored
      This patch implements an improvment that I've wanted to do for ages, but
      never gotten around to.
      
      Unused imports are computed based on how imported entities occur (qualified,
      unqualified).   This info was accumulated in tcg_used_rdrnames :: Set RdrName.
      But that was a huge pain, and it got worse when we introduced duplicate
      record fields.
      
      The Right Thing is to record tcg_used_gres :: [GlobalRdrElt], which records
      the GRE *after* filtering with pickGREs.  See Note [GRE filtering] in RdrName.
      This is much, much bette.  This patch deletes quite a bit of code, and is
      conceptually much easier to follow.
      
      Hooray.  There should be no change in functionality.
      3e94842d
  21. 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
  22. 19 Oct, 2015 1 commit
  23. 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
  24. 02 Sep, 2015 1 commit
    • Eric Seidel's avatar
      Use IP based CallStack in error and undefined · 6740d70d
      Eric Seidel authored
      This patch modifies `error`, `undefined`, and `assertError` to use
      implicit call-stacks to provide better error messages to users.
      
      There are a few knock-on effects:
      
      - `GHC.Classes.IP` is now wired-in so it can be used in the wired-in
        types for `error` and `undefined`.
      
      - `TysPrim.tyVarList` has been replaced with a new function
        `TysPrim.mkTemplateTyVars`. `tyVarList` made it easy to introduce
        subtle bugs when you need tyvars of different kinds. The naive
      
        ```
        tv1 = head $ tyVarList kind1
        tv2 = head $ tyVarList kind2
        ```
      
        would result in `tv1` and `tv2` sharing a `Unique`, thus substitutions
        would be applied incorrectly, treating `tv1` and `tv2` as the same
        tyvar. `mkTemplateTyVars` avoids this pitfall by taking a list of kinds
        and producing a single tyvar of each kind.
      
      - The types `GHC.SrcLoc.SrcLoc` and `GHC.Stack.CallStack` now live in
        ghc-prim.
      
      - The type `GHC.Exception.ErrorCall` has a new constructor
        `ErrorCallWithLocation` that takes two `String`s instead of one, the
        2nd one being arbitrary metadata about the error (but usually the
        call-stack). A bi-directional pattern synonym `ErrorCall` continues to
        provide the old API.
      
      Updates Cabal, array, and haddock submodules.
      
      Reviewers: nh2, goldfire, simonpj, hvr, rwbarton, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, rodlogic, goldfire, maoe, simonmar, carter,
      liyang, bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D861
      
      GHC Trac Issues: #5273
      6740d70d
  25. 05 Aug, 2015 1 commit
    • Simon Peyton Jones's avatar
      Tidy up and refactor wildcard handling · 95364812
      Simon Peyton Jones authored
      When examining #10615, I found the wildcard handling hard
      to understand.  This patch refactors quite a bit, but with
      no real change in behaviour.
      
       * Split out TcIdSigInfo from TcSigInfo, as a separate type,
         like TcPatSynInfo.
      
       * Make TcIdSigInfo express more invariants by pushing the
         wildard info into TcIdSigBndr
      
       * Remove all special treatment of unification variables that arise
         from wildcards; so the TauTv of TcType.MetaInfo loses its Bool
         argument.
      
      A ton of konck on changes.  The result is significantly simpler, I think.
      95364812
  26. 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
  27. 21 Jul, 2015 1 commit
  28. 26 Jun, 2015 2 commits
    • Simon Peyton Jones's avatar
      Treat out-of-scope variables as holes · fb7b6922
      Simon Peyton Jones authored
      This patch implements the idea in Trac #10569.
      
      * An out-of-scope variable is treated as a typed expression
        hole.
      
      * That is, we don't report it in the type checker, not the
        renamer, and we when we do report it, we give its type.
      
      * Moreover, we can defer the error to runtime with
        -fdefer-typed-holes
      
      In implementation terms:
      
      * The renamer turns an unbound variable into a HsUnboundVar
      
      * The type checker emits a Hole constraint for a
        HsUnboundVar, and turns it back into a HsVar
      
      It was a bit painful to implement because a whole raft of
      error messages change slightly.  But there was absolutely
      nothing hard in principle.
      
      Holes are reported with a bunch of possibly-useful context,
      notably the "relevant bindings".  I found that this was
      distracting clutter in the very common case of a mis-typed
      variable that is only accidentally not in scope, so I've
      arranged to print the context information only for true holes,
      that is ones starting with an underscore.
      
      Unbound data constructors use in patterns, like
        f (D x) = x
      are still reportd by the renamer, and abort compilation
      before type checking.
      fb7b6922
    • Simon Peyton Jones's avatar
      Use a Representaional coercion for data families · ff8a6716
      Simon Peyton Jones authored
      When we have
        data instance T (a,b) = MkT a b
      we make a represntation type
        data TPair a b = MkT a b
      plus an axiom to connect the two
        ax a b :: T (a,b)  ~R  TPair a b
      
      Previously this was a Nominal equality, and that worked ok
      but seems illogical since Nominal equalities are between
      types that the programmer thinks of as being equal.  But
      TPair is not visible to the programmer; indeed we call it
      the "representation TyCon".  So a Representational equality
      seems more suitable here.
      ff8a6716
  29. 18 Jun, 2015 1 commit
    • Simon Peyton Jones's avatar
      Rename getCtLoc, setCtLoc · 4a7a6c3a
      Simon Peyton Jones authored
      getCtLoc -> getCtLocM
      setCtLoc -> setCtLocM
      
      These operations are monadic, and I want to introduce a
      pure version of setCtLoc :: Ct -> CtLoc -> Ct
      4a7a6c3a
  30. 18 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · ffc21506
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      
      - Haddock needs to absorb the change too; so there is a submodule update
      ffc21506
  31. 14 May, 2015 1 commit
    • Austin Seipp's avatar
      Revert multiple commits · 3cf8ecdc
      Austin Seipp authored
      This reverts multiple commits from Simon:
      
        - 04a484ea Test Trac #10359
        - a9ccd37a Test Trac #10403
        - c0aae6f6 Test Trac #10248
        - eb6ca851 Make the "matchable-given" check happen first
        - ca173aa3 Add a case to checkValidTyCon
        - 51cbad15 Update haddock submodule
        - 6e1174da Separate transCloVarSet from fixVarSet
        - a8493e03 Fix imports in HscMain (stage2)
        - a154944b Two wibbles to fix the build
        - 5910a1bc Change in capitalisation of error msg
        - 130e93aa Refactor tuple constraints
        - 8da785d5 Delete commented-out line
      
      These break the build by causing Haddock to fail mysteriously when
      trying to examine GHC.Prim it seems.
      3cf8ecdc
  32. 13 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor tuple constraints · 130e93aa
      Simon Peyton Jones authored
      Make tuple constraints be handled by a perfectly ordinary
      type class, with the component constraints being the
      superclasses:
          class (c1, c2) => (c2, c2)
      
      This change was provoked by
      
        #10359  inability to re-use a given tuple
                constraint as a whole
      
        #9858   confusion between term tuples
                and constraint tuples
      
      but it's generally a very nice simplification. We get rid of
       -  In Type, the TuplePred constructor of PredTree,
          and all the code that dealt with TuplePreds
       -  In TcEvidence, the constructors EvTupleMk, EvTupleSel
      
      See Note [How tuples work] in TysWiredIn.
      
      Of course, nothing is ever entirely simple. This one
      proved quite fiddly.
      
      - I did quite a bit of renaming, which makes this patch
        touch a lot of modules. In partiuclar tupleCon -> tupleDataCon.
      
      - I made constraint tuples known-key rather than wired-in.
        This is different to boxed/unboxed tuples, but it proved
        awkward to have all the superclass selectors wired-in.
        Easier just to use the standard mechanims.
      
      - While I was fiddling with known-key names, I split the TH Name
        definitions out of DsMeta into a new module THNames.  That meant
        that the known-key names can all be gathered in PrelInfo, without
        causing module loops.
      
      - I found that the parser was parsing an import item like
            T( .. )
        as a *data constructor* T, and then using setRdrNameSpace to
        fix it.  Stupid!  So I changed the parser to parse a *type
        constructor* T, which means less use of setRdrNameSpace.
      
        I also improved setRdrNameSpace to behave better on Exact Names.
        Largely on priciple; I don't think it matters a lot.
      
      - When compiling a data type declaration for a wired-in thing like
        tuples (,), or lists, we don't really need to look at the
        declaration.  We have the wired-in thing!  And not doing so avoids
        having to line up the uniques for data constructor workers etc.
        See Note [Declarations for wired-in things]
      
      - I found that FunDeps.oclose wasn't taking superclasses into
        account; easily fixed.
      
      - Some error message refactoring for invalid constraints in TcValidity
      130e93aa
  33. 11 May, 2015 1 commit
    • Edward Z. Yang's avatar
      Support stage 1 Template Haskell (non-quasi) quotes, fixes #10382. · f16ddcee
      Edward Z. Yang authored
      Summary:
      This commit adds stage 1 support for Template Haskell
      quoting, e.g. [| ... expr ... |], which is useful
      for authors of quasiquoter libraries that do not actually
      need splices.  The TemplateHaskell extension now does not
      unconditionally fail; it only fails if the renamer encounters
      a splice that it can't run.
      
      In order to make sure the referenced data structures
      are consistent, template-haskell is now a boot library.
      There are some minor BC changes to template-haskell to make it boot
      on GHC 7.8.
      
      Note for reviewer: big diff changes are simply code
      being moved out of an ifdef; there was no other substantive
      change to that code.
      Signed-off-by: default avatarEdward Z. Yang <ezyang@cs.stanford.edu>
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, goldfire
      
      Subscribers: bgamari, thomie
      
      Differential Revision: https://phabricator.haskell.org/D876
      
      GHC Trac Issues: #10382
      f16ddcee
  34. 09 May, 2015 2 commits
  35. 06 May, 2015 1 commit