1. 05 Sep, 2016 1 commit
  2. 30 Aug, 2016 1 commit
  3. 29 Aug, 2016 1 commit
    • Ryan Scott's avatar
      Remove unused DerivInst constructor for DerivStuff · f4384ef5
      Ryan Scott authored
      Summary:
      Back when derived `Generic` instances used to generate auxiliary datatypes,
      they would also generate instances for those datatypes. Nowadays, GHC generics
      uses a `DataKinds`-based encoding that requires neither auxiliary datatypes
      (corresponding to the `DerivTyCon` constructor of `DerivStuff`) nor instances
      for them (the `DerivInst` constructor of `DerivStuff`). It appears that
      `DerivTyCon` constructor was removed at some point, but `DerivInst` never was.
      
      No `DerivInst` values are ever constructed, so we can safely remove it.
      
      Test Plan: It builds
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2481
      f4384ef5
  4. 18 Jul, 2016 1 commit
    • Ryan Scott's avatar
      Make DeriveFunctor work with unboxed tuples · 3fa3fe8a
      Ryan Scott authored
      Summary:
      Unboxed tuples have `RuntimeRep` arguments which `-XDeriveFunctor` was
      mistaking for actual data constructor arguments. As a result, a derived
      `Functor` instance for a datatype that contained an unboxed tuple would
      generate twice as many arguments as it needed for an unboxed tuple pattern
      match or expression. The solution is to simply put `dropRuntimeRepArgs` in the
      right place.
      
      Fixes #12399.
      
      Test Plan: ./validate
      
      Reviewers: austin, hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, osa1
      
      Differential Revision: https://phabricator.haskell.org/D2404
      
      GHC Trac Issues: #12399
      3fa3fe8a
  5. 05 Jul, 2016 1 commit
    • Simon Peyton Jones's avatar
      Make unique auxiliary function names in deriving · 895eefa8
      Simon Peyton Jones authored
      In deriving for Data, we make some auxiliary functions, but they
      didn't always get distinct names (Trac #12245).  This patch fixes
      it by using the same mechanism as for dictionary functions, namely
      chooseUniqueOccTc.
      
      Some assocated refactoring came along for the ride.
      895eefa8
  6. 25 Jun, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      s/Invisible/Inferred/g s/Visible/Required/g · 5fdb854c
      eir@cis.upenn.edu authored
      This renames VisibilityFlag from
      
      > data VisibilityFlag = Visible | Specified | Invisible
      
      to
      
      > data ArgFlag = Required | Specified | Inferred
      
      The old name was quite confusing, because both Specified
      and Invisible were invisible! The new names are hopefully clearer.
      5fdb854c
  7. 15 Jun, 2016 1 commit
    • Simon Peyton Jones's avatar
      Re-add FunTy (big patch) · 77bb0927
      Simon Peyton Jones authored
      With TypeInType Richard combined ForAllTy and FunTy, but that was often
      awkward, and yielded little benefit becuase in practice the two were
      always treated separately.  This patch re-introduces FunTy.  Specfically
      
      * New type
          data TyVarBinder = TvBndr TyVar VisibilityFlag
        This /always/ has a TyVar it.  In many places that's just what
        what we want, so there are /lots/ of TyBinder -> TyVarBinder changes
      
      * TyBinder still exists:
          data TyBinder = Named TyVarBinder | Anon Type
      
      * data Type = ForAllTy TyVarBinder Type
                  | FunTy Type Type
                  |  ....
      
      There are a LOT of knock-on changes, but they are all routine.
      
      The Haddock submodule needs to be updated too
      77bb0927
  8. 06 Jun, 2016 1 commit
    • Alan Zimmerman's avatar
      Merge MatchFixity and HsMatchContext · a13cb279
      Alan Zimmerman authored
      Summary:
      MatchFixity was introduced to facilitate use of API Annotations.
      
      HsMatchContext does the same thing with more detail, but is chased
      through all over the place to provide context when processing a Match.
      
      Since we already have MatchFixity in the Match, it may as well provide
      the full context.
      
      updates submodule haddock
      
      Test Plan: ./validate
      
      Reviewers: austin, goldfire, bgamari
      
      Subscribers: thomie, mpickering
      
      Differential Revision: https://phabricator.haskell.org/D2271
      
      GHC Trac Issues: #12105
      
      (cherry picked from commit 306ecad5)
      a13cb279
  9. 21 May, 2016 1 commit
    • Andrew Farmer's avatar
      Fix deriving Ord when RebindableSyntax is enabled · 527ed724
      Andrew Farmer authored
      Deriving clauses (Ord especially) generated if-expressions with nlHsIf
      which were subject to RebindableSyntax. This changes nlHsIf to generate
      concrete if-expressions.
      
      There was also an error about calling tagToEnum# at a polymorphic type,
      which is not allowed. Fixing nlHsIf didn't fix this for some reason, so
      I generated a type ascription around the call to tagToEnum#. Not sure
      why the typechecker could not figure this out.
      
      Test Plan: Added a test, ran validate.
      
      Reviewers: simonpj, simonmar, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2247
      
      GHC Trac Issues: #12080
      527ed724
  10. 24 Mar, 2016 1 commit
    • Ben Gamari's avatar
      Show: Restore redundant parentheses around records · 1448f8ab
      Ben Gamari authored
      As discussed in #2530 we are going to continue to produce parentheses
      here in order to preserve compatibility with previous GHC releases. It
      was found that dropped parentheses would break some testsuites which
      compared against output from Show. This has been documented in the users
      guide.
      
      This reverts commit 5692643c.
      
      Test Plan: Validate
      
      Reviewers: hvr, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2027
      
      GHC Trac Issues: #2350
      1448f8ab
  11. 18 Feb, 2016 1 commit
  12. 17 Feb, 2016 1 commit
    • Ryan Scott's avatar
      Remove superfluous code when deriving Foldable/Traversable · a82956df
      Ryan Scott authored
      Currently, `-XDeriveFoldable` and `-XDeriveTraversable` generate
      unnecessary `mempty` and `pure` expressions when it traverses of an
      argument of a constructor whose type does not mention the last type
      parameter. Not only is this inefficient, but it prevents `Traversable`
      from being derivable for datatypes with unlifted arguments (see
      Trac #11174).
      
      The solution to this problem is to adopt a slight change to the
      algorithms for `-XDeriveFoldable` and `-XDeriveTraversable`, which is
      described in [this wiki
      page](https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/DeriveFu
      nctor#Proposal:alternativestrategyforderivingFoldableandTraversable).
      The wiki page also describes why we don't apply the same changes to the
      algorithm for `-XDeriveFunctor`.
      
      This is techincally a breaking change for users of `-XDeriveFoldable`
      and `-XDeriveTraversable`, since if someone was using a law-breaking
      `Monoid` instance with a derived `Foldable` instance (i.e., one where `x
      <> mempty` does not equal `x`) or a law-breaking `Applicative` instance
      with a derived `Traversable` instance, then the new generated code could
      result in different behavior. I suspect the number of scenarios like
      this is very small, and the onus really should be on those users to fix
      up their `Monoid`/`Applicative` instances.
      
      Fixes #11174.
      
      Test Plan: ./validate
      
      Reviewers: hvr, simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1908
      
      GHC Trac Issues: #11174
      a82956df
  13. 08 Feb, 2016 2 commits
  14. 27 Jan, 2016 2 commits
    • 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
    • Ömer Sinan Ağacan's avatar
      s/unLifted/unlifted for consistency · 4faa1a63
      Ömer Sinan Ağacan authored
      This was causing trouble as we had to remember when to use "unLifted"
      and when to use "unlifted".
      
      "unlifted" is used instead of "unLifted" as it's a single word.
      
      Reviewers: austin, hvr, goldfire, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1852
      4faa1a63
  15. 20 Jan, 2016 1 commit
    • Ben Gamari's avatar
      Use (&&) instead of `if` in Ix derivation · 5cce0954
      Ben Gamari authored
      We were previously using `if` in the derivation of `Ix` instances. This
      interacts badly with RebindableSyntax as the typechecker doesn't infer
      the type of the argument we give to `tagToEnum#`.
      
      Previously we produced, `if (ch >= ah) then (ch <= bh) else False`.
      
      We now produce `(ch >= ah) && (ch <= bh)`
      
      Fixes #11396.
      
      Test Plan: Validate
      
      Reviewers: austin, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1797
      
      GHC Trac Issues: #11396
      5cce0954
  16. 18 Jan, 2016 1 commit
    • 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
  17. 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
  18. 31 Dec, 2015 1 commit
  19. 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
  20. 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
  21. 09 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Fix DeriveAnyClass (Trac #9968) · af77089b
      Simon Peyton Jones authored
      The main issue concerned things like
      
         data T a = MkT a deriving( C Int )
      
      which is supposed to generate
      
         instance C Int (T a) where {}
      
      But the 'Int' argument (called cls_tys in the code) wasn't
      even being passed to inferConstraints and mk_data_eqn, so it
      really had no chance.   DeriveAnyClass came along after this
      code was written!
      
      Anyway I did quite a bit of tidying up in inferConstraints.
      
      Also I discovered that this case was not covered at all
      
         data T a b = MkT a b deriving( Bifunctor )
      
      What constraints should we generate for the instance context?
      We can deal with classes whose last arg has kind *, like Eq, Ord;
      or (* -> *), like Functor, Traversable.  But we really don't have
      a story for classes whose last arg has kind (* -> * -> *).
      
      So I augmented checkSideConditions to check for that and give
      a sensible error message.
      
      ToDo: update the user manual.
      af77089b
  22. 07 Dec, 2015 1 commit
  23. 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
  24. 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
  25. 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
  26. 15 Oct, 2015 1 commit
  27. 03 Oct, 2015 1 commit
    • Ryan Scott's avatar
      Fill in associated type defaults with DeriveAnyClass · 2f74be9c
      Ryan Scott authored
      Summary:
      Unlike `-XDefaultSignatures`, `-XDeriveAnyClass` would not fill in
      associated type family defaults when deriving a class which contained
      them.
      
      In order to fix this properly, `tcATDefault` needed to be used from
      `TcGenDeriv`. To avoid a module import cycle, `tcATDefault` was moved
      from `TcInstDcls` to `TcClsDcl`.
      
      Fixes #10361.
      
      Test Plan: ./validate
      
      Reviewers: kosmikus, dreixel, bgamari, austin, simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1283
      
      GHC Trac Issues: #10361
      2f74be9c
  28. 22 Sep, 2015 2 commits
    • Ryan Scott's avatar
      DeriveLift extension (#1830) · 089b72f5
      Ryan Scott authored
      Summary:
      This implements -XDeriveLift, which allows for automatic derivation
      of the Lift class from template-haskell. The implementation is based
      off of Ian Lynagh's th-lift library
      (http://hackage.haskell.org/package/th-lift).
      
      Test Plan: ./validate
      
      Reviewers: hvr, simonpj, bgamari, goldfire, austin
      
      Reviewed By: goldfire, austin
      
      Subscribers: osa1, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1168
      
      GHC Trac Issues: #1830
      089b72f5
    • niteria's avatar
      Make derived names deterministic · d4d34a73
      niteria authored
      The names of auxiliary bindings end up in the interface file, and since uniques
      are nondeterministic, we end up with nondeterministic interface files.
      
      This uses the package and module name in the generated name, so I believe it
      should avoid problems from #7947 and be deterministic as well.
      
      The generated names look like this now:
      
        `$cLrlbmVwI3gpI8G2E6Hg3mO`
      
      and with `-ppr-debug`:
      
        `$c$aeson_70dylHtv1FFGeai1IoxcQr$Data.Aeson.Types.Internal$String`.
      
      Reviewed By: simonmar, austin, ezyang
      
      Differential Revision: https://phabricator.haskell.org/D1133
      
      GHC Trac Issues: #4012
      d4d34a73
  29. 16 Jul, 2015 1 commit
  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. 06 May, 2015 2 commits
  34. 01 May, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor TyCon to eliminate TupleTyCon · f6ab0f2d
      Simon Peyton Jones authored
      This makes TupleTyCon into an ordinary AlgTyCon, distinguished
      by its AlgTyConRhs, rather than a separate constructor of TyCon.
      
      It is preparatory work for making constraint tuples into classes,
      for which the ConstraintTuple tuples will have a TyConParent
      of a ClassTyCon.  Tuples didn't have this possiblity before.
      
      The patch affects other modules because I eliminated the
      unsatisfactory partial functions tupleTyConBoxity and tupleTyConSort.
      And tupleTyConArity which is just tyConArity.
      f6ab0f2d
  35. 07 Apr, 2015 1 commit
  36. 16 Mar, 2015 1 commit
    • thomie's avatar
      Dont call unsafeGlobalDynFlags if it is not set · 5166ee94
      thomie authored
      Parsing of static and mode flags happens before any session is started,
      i.e., before the first call to 'GHC.withGhc'. Therefore, to report
      errors for invalid usage of these two types of flags, we can not call
      any function that needs DynFlags, as there are no DynFlags available yet
      (unsafeGlobalDynFlags is not set either). So we always print "on the
      commandline" as the location, which is true except for Api users, which
      is probably ok.
      
      When reporting errors for invalid usage of dynamic flags we /can/ make
      use of DynFlags, and we do so explicitly in
      DynFlags.parseDynamicFlagsFull.
      
      Before, we called unsafeGlobalDynFlags when an invalid (combination of)
      flag(s) was given on the commandline, resulting in panics (#9963). This
      regression was introduced in 1d6124de.
      
      Also rename showSDocSimple to showSDocUnsafe, to hopefully prevent this
      from happening again.
      
      Reviewed By: austin
      
      Differential Revision: https://phabricator.haskell.org/D730
      
      GHC Trac Issues: #9963
      5166ee94