1. 24 Sep, 2016 1 commit
    • Joachim Breitner's avatar
      Replace INLINEABLE by INLINABLE (#12613) · 68f72f10
      Joachim Breitner authored
      as the latter is the official, correct spelling, and the former just a
      misspelling accepted by GHC.
      
      Also document in the user’s guide that the alternative spelling is
      accepted
      
      This commit was brough to you by HIW 2016.
      68f72f10
  2. 07 Jul, 2016 1 commit
  3. 24 Jun, 2016 1 commit
  4. 22 Jun, 2016 1 commit
    • niteria's avatar
      Make the Ord Module independent of Unique order (2nd try) · 348f2dbb
      niteria authored
      The `Ord Module` instance currently uses `Unique`s for comparison.
      We don't want to use the `Unique` order because it can introduce
      nondeterminism.
      This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic
      ordering making `Ord Module` deterministic transitively.
      
      I've run `nofib` and it doesn't make a measurable difference.
      
      See also Note [ModuleEnv determinism and performance].
      
      This fixes #12191 - the regression, that the previous version of this
      patch had.
      
      Test Plan:
      ./validate
      run nofib: P112
      
      Reviewers: simonmar, bgamari, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2354
      
      GHC Trac Issues: #4012, #12191
      348f2dbb
  5. 20 Jun, 2016 2 commits
  6. 15 Jun, 2016 2 commits
    • Simon Peyton Jones's avatar
      Major patch to introduce TyConBinder · e368f326
      Simon Peyton Jones authored
      Before this patch, following the TypeInType innovations,
      each TyCon had two lists:
        - tyConBinders :: [TyBinder]
        - tyConTyVars  :: [TyVar]
      
      They were in 1-1 correspondence and contained
      overlapping information.  More broadly, there were many
      places where we had to pass around this pair of lists,
      instead of a single list.
      
      This commit tidies all that up, by having just one list of
      binders in a TyCon:
      
        - tyConBinders :: [TyConBinder]
      
      The new data types look like this:
      
        Var.hs:
           data TyVarBndr tyvar vis = TvBndr tyvar vis
           data VisibilityFlag = Visible | Specified | Invisible
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
      
        TyCon.hs:
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
      
           data TyConBndrVis
             = NamedTCB VisibilityFlag
             | AnonTCB
      
        TyCoRep.hs:
           data TyBinder
             = Named TyVarBinder
             | Anon Type
      
      Note that Var.TyVarBdr has moved from TyCoRep and has been
      made polymorphic in the tyvar and visiblity fields:
      
           type TyVarBinder = TyVarBndr TyVar VisibilityFlag
              -- Used in ForAllTy
           type TyConBinder = TyVarBndr TyVar TyConBndrVis
              -- Used in TyCon
      
           type IfaceForAllBndr  = TyVarBndr IfaceTvBndr VisibilityFlag
           type IfaceTyConBinder = TyVarBndr IfaceTvBndr TyConBndrVis
               -- Ditto, in interface files
      
      There are a zillion knock-on changes, but everything
      arises from these types.  It was a bit fiddly to get the
      module loops to work out right!
      
      Some smaller points
      ~~~~~~~~~~~~~~~~~~~
      * Nice new functions
          TysPrim.mkTemplateKiTyVars
          TysPrim.mkTemplateTyConBinders
        which help you make the tyvar binders for dependently-typed
        TyCons.  See comments with their definition.
      
      * The change showed up a bug in TcGenGenerics.tc_mkRepTy, where the code
        was making an assumption about the order of the kind variables in the
        kind of GHC.Generics.(:.:).  I fixed this; see TcGenGenerics.mkComp.
      e368f326
    • Simon Peyton Jones's avatar
      Revert "Make the Ord Module independent of Unique order" · 70a45893
      Simon Peyton Jones authored
      This reverts commit 0497ee50.
      
      Reason: See Trac #12191.  I'm reverting pending Bartosz's
      investigation of what went wrong.
      70a45893
  7. 13 Jun, 2016 2 commits
    • niteria's avatar
      Make the Ord Module independent of Unique order · 0497ee50
      niteria authored
      The `Ord Module` instance currently uses `Unique`s for comparison.
      We don't want to use the `Unique` order because it can introduce nondeterminism.
      This switches `Ord ModuleName` and `Ord UnitId` to use lexicographic ordering
      making `Ord Module` deterministic transitively.
      
      I've run `nofib` and it doesn't make a measurable difference.
      
      See also Note [ModuleEnv determinism and performance].
      
      Test Plan:
      ./validate
      run nofib: P112
      
      Reviewers: simonpj, simonmar, austin, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2030
      
      GHC Trac Issues: #4012
      0497ee50
    • Simon Peyton Jones's avatar
      Improve typechecking of let-bindings · 15b9bf4b
      Simon Peyton Jones authored
      This major commit was initially triggered by #11339, but it spiraled
      into a major review of the way in which type signatures for bindings
      are handled, especially partial type signatures.  On the way I fixed a
      number of other bugs, namely
         #12069
         #12033
         #11700
         #11339
         #11670
      
      The main change is that I completely reorganised the way in which type
      signatures in bindings are handled. The new story is in TcSigs
      Note [Overview of type signatures].  Some specific:
      
      * Changes in the data types for signatures in TcRnTypes:
        TcIdSigInfo and new TcIdSigInst
      
      * New module TcSigs deals with typechecking type signatures
        and pragmas. It contains code mostly moved from TcBinds,
        which is already too big
      
      * HsTypes: I swapped the nesting of HsWildCardBndrs
        and HsImplicitBndsrs, so that the wildcards are on the
        oustide not the insidde in a LHsSigWcType.  This is just
        a matter of convenient, nothing deep.
      
      There are a host of other changes as knock-on effects, and
      it all took FAR longer than I anticipated :-).  But it is
      a significant improvement, I think.
      
      Lots of error messages changed slightly, some just variants but
      some modest improvements.
      
      New tests
      
      * typecheck/should_compile
          * SigTyVars: a scoped-tyvar test
          * ExPat, ExPatFail: existential pattern bindings
          * T12069
          * T11700
          * T11339
      
      * partial-sigs/should_compile
          * T12033
          * T11339a
          * T11670
      
      One thing to check:
      
      * Small change to output from ghc-api/landmines.
        Need to check with Alan Zimmerman
      15b9bf4b
  8. 09 Jun, 2016 1 commit
    • Facundo Domínguez's avatar
      Improve the error messages for static forms. · e9dfb6e5
      Facundo Domínguez authored
      Now the message explains why closed variables are not closed when
      encountered in the body of (static ...).
      
      This required adding to the local environment the free variables of
      the local bindings in scope. Thus we can analyze and explain why a
      variable is not closed when encountered.
      
      Test Plan: ./validate
      
      Reviewers: austin, simonpj, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: mboes, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2167
      
      GHC Trac Issues: #12003
      e9dfb6e5
  9. 18 May, 2016 1 commit
    • niteria's avatar
      Kill varSetElems in tidyFreeTyCoVars · 6282bc31
      niteria authored
      I haven't observed this to have an effect on nondeterminism,
      but tidyOccName appears to modify the TidyOccEnv in a
      way dependent on the order of inputs.
      It's easy enough to change it to be deterministic to be on the
      safe side.
      
      Test Plan: ./validate
      
      Reviewers: simonmar, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2238
      
      GHC Trac Issues: #4012
      6282bc31
  10. 02 May, 2016 1 commit
    • Facundo Domínguez's avatar
      StaticPointers: Allow closed vars in the static form. · 36d29f7c
      Facundo Domínguez authored
      Summary:
      With this patch closed variables are allowed regardless of whether
      they are bound at the top level or not.
      
      The FloatOut pass is always performed. When optimizations are
      disabled, only expressions that go to the top level are floated.
      Thus, the applications of the StaticPtr data constructor are always
      floated.
      
      The CoreTidy pass makes sure the floated applications appear in the
      symbol table of object files. It also collects the floated bindings
      and inserts them in the static pointer table.
      
      The renamer does not check anymore if free variables appearing in the
      static form are top-level. Instead, the typechecker looks at the
      tct_closed flag to decide if the free variables are closed.
      
      The linter checks that applications of StaticPtr only occur at the
      top of top-level bindings after the FloatOut pass.
      
      The field spInfoName of StaticPtrInfo has been removed. It used to
      contain the name of the top-level binding that contains the StaticPtr
      application. However, this information is no longer available when the
      StaticPtr is constructed, as the binding name is determined now by the
      FloatOut pass.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, austin, hvr, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie, mpickering, mboes
      
      Differential Revision: https://phabricator.haskell.org/D2104
      
      GHC Trac Issues: #11656
      36d29f7c
  11. 28 Apr, 2016 1 commit
  12. 26 Apr, 2016 1 commit
    • niteria's avatar
      Kill varSetElemsWellScoped in quantifyTyVars · c9bcaf31
      niteria authored
      varSetElemsWellScoped introduces unnecessary non-determinism in
      inferred type signatures.
      Removing this instance required changing the representation of
      TcDepVars to use deterministic sets.
      This is the last occurence of varSetElemsWellScoped, allowing me to
      finally remove it.
      
      Test Plan:
      ./validate
      I will update the expected outputs when commiting, some reordering
      of type variables in types is expected.
      
      Reviewers: goldfire, simonpj, austin, bgamari
      
      Reviewed By: simonpj
      
      Subscribers: thomie, simonmar
      
      Differential Revision: https://phabricator.haskell.org/D2135
      
      GHC Trac Issues: #4012
      c9bcaf31
  13. 29 Mar, 2016 1 commit
  14. 21 Mar, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Track specified/invisible more carefully. · 35e93797
      eir@cis.upenn.edu authored
      In particular, this allows correct tracking of specified/invisible
      for variables in Haskell98 data constructors and in pattern synonyms.
      GADT-syntax constructors are harder, and are left until #11721.
      
      This was all inspired by Simon's comments to my fix for #11512,
      which this subsumes.
      
      Test case: ghci/scripts/TypeAppData
      
      [skip ci]  (The test case fails because of an unrelated problem
      fixed in the next commit.)
      35e93797
  15. 05 Mar, 2016 1 commit
  16. 25 Feb, 2016 3 commits
  17. 23 Feb, 2016 3 commits
  18. 17 Feb, 2016 1 commit
  19. 15 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Improve error message suppression · 18cd7124
      Simon Peyton Jones authored
      TcErrors has a system for suppressing some type errors if a more
      serious one occurs.  But there was a crucial missing case, which
      sometimes resulted in a cascade of irrelevant errors overwhelming
      the actual cause. This was Trac #11541.
      
      The fix is simple.  Worth merging to 8.0
      18cd7124
  20. 10 Feb, 2016 1 commit
  21. 08 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Allow foralls in instance decls · 2cf3cac6
      Simon Peyton Jones authored
      This patch finally makes it possible to have explicit
      foralls in an instance decl
         instance forall (a :: *). Eq a => Eq [a] where ...
      
      This is useful to allow kind signatures or indeed
      explicicit kind for-alls; see Trac #11519
      
      I thought it would be really easy, because an instance
      declaration already contains an actual HsSigType, so all
      the syntactic baggage is there.  But in fact it turned
      out that instance declarations were kind-checked a
      little differently, because the body kind of the forall
      is 'Constraint' rather than '*'.
      
      So I fixed that.  There a slight kludge
      (see Note [Body kind of a HsQualTy], but it's still a
      significant improvement.
      
      I also did the usual other round of refactoring,
      improved a few error messages, tidied up comments etc.
      The only significant aspect of all that was
      
        * Kill mkNakedSpecSigmaTy, mkNakedPhiTy, mkNakedFunTy
          These function names suggest that they do something
          complicated, but acutally they do nothing. So I
          killed them.
      
        * Swap the arg order of mkNamedBinder, just so that it is
          convenient to say 'map (mkNamedBinder Invisible) tvs'
      
        * I had to improve isPredTy, to deal with (illegal)
          types like
             (Eq a => Eq [a]) => blah
          See Note [isPeredTy complications] in Type.hs
      
      Still to come: user manual documentation for the
      instance-decl change.
      2cf3cac6
  22. 21 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Re-add missing kind generalisation · c572430c
      Simon Peyton Jones authored
      When splitting H98/GADT syntax in ConDecl we lost a key
      kind-generalisation step.
      
      I also renamed tcHsTyVarBndrs to tcExplicitTKBnders, by analogy
      with tcImplicitTkBndrs.
      
      This fixes Trac #11459.
      
      Merge to 8.0.
      c572430c
  23. 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
  24. 15 Dec, 2015 1 commit
    • Ben Gamari's avatar
      Narrow scope of special-case for unqualified printing of names in core libraries · e2c91738
      Ben Gamari authored
      Commit 547c5971 modifies the
      pretty-printer to render names from a set of core packages (`base`,
      `ghc-prim`, `template-haskell`) as unqualified. The idea here was that
      many of these names typically are not in scope but are well-known by the
      user and therefore qualification merely introduces noise.
      
      This, however, is a very large hammer and potentially breaks any
      consumer who relies on parsing GHC output (hence #11208). This commit
      partially reverts this change, now only printing `Constraint` (which
      appears quite often in errors) as unqualified.
      
      Fixes #11208.
      
      Updates tests in `array` submodule.
      
      Test Plan: validate
      
      Reviewers: hvr, thomie, austin
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1619
      
      GHC Trac Issues: #11208
      e2c91738
  25. 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
  26. 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
  27. 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
  28. 18 Nov, 2015 1 commit
    • Joachim Breitner's avatar
      More import related hints · 11e336e4
      Joachim Breitner authored
      Now for unqualified imports. Improves upon #11071.
      
      Unfortunately, it seems that since 7.10, ghc will not print all
      out-of-scope errors.
      
      Test Plan: test suite updated
      
      Reviewers: austin, thomie, bgamari
      
      Reviewed By: bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1478
      
      GHC Trac Issues: #11071
      11e336e4
  29. 13 Nov, 2015 1 commit
  30. 01 Nov, 2015 1 commit
    • Herbert Valerio Riedel's avatar
      Bump `base` version to 4.9.0.0 (closes #11026) · f8ba4b55
      Herbert Valerio Riedel authored
      This also relaxes a few upper bounds on base in the ghc.git repo;
      
      This required a mass-rewrite in testsuite/
      
        sed -i s,base-4.8.2.0,base-4.9.0.0,g $(git grep -Fl 'base-4.8.2.0')
      
      because it turns out the testsuite is still sensitive to package version
      changes.
      f8ba4b55
  31. 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
  32. 08 Oct, 2015 1 commit
  33. 17 Sep, 2015 1 commit