1. 11 Apr, 2016 1 commit
    • Rik Steenkamp's avatar
      Fix a closed type family error message · 46e8f199
      Rik Steenkamp authored
      Now we check whether a closed type family's equation is headed with
      the correct type before we kind-check the equation.
      
      Also, instead of "expected only no parameters" we now generate the
      message "expected no parameters".
      
      Fixes #11623.
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: simonpj, goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D2089
      
      GHC Trac Issues: #11623
      46e8f199
  2. 25 Mar, 2016 1 commit
    • Simon Peyton Jones's avatar
      A raft of comments about TyBinders · 067335a6
      Simon Peyton Jones authored
      I had a conversation with Richard about TyBinders
      and VisibilityFlags.  This patch adds a lot of comments
      to explain what is going on.  I feel much more secure now.
      
      Richard please check.
      067335a6
  3. 21 Mar, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Zonk before calling splitDepVarsOfType. · 5c0c751a
      eir@cis.upenn.edu authored
      It was Utterly Wrong before.
      
      Note to self: Never, ever take the free vars of an unzonked type.
      5c0c751a
    • 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
  4. 17 Mar, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Fix #11716. · 3fe87aa0
      eir@cis.upenn.edu authored
      There were several smallish bugs here:
       - We had too small an InScopeSet when rejigging GADT return types.
       - When adding the extra_tvs with a datatype kind signature, we
         were sometimes changing Uniques of an explicitly bound kind var.
       - Using coercionKind in the flattener got the wrong visibility
         for a binder. Now we just zonk to get what we need.
      
      Test case: dependent/should_compile/RaeJobTalk
      3fe87aa0
  5. 15 Mar, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Remove redundant anonymiseTyBinders (#11648) · 19be5385
      eir@cis.upenn.edu authored
      This was necessary in an earlier version of the patch for #11648,
      but not in the final version. I forgot to remove it.
      19be5385
    • eir@cis.upenn.edu's avatar
      Fix #11648. · 55577a91
      eir@cis.upenn.edu authored
      We now check that a CUSK is really a CUSK and issue an error if
      it isn't. This also involves more solving and zonking in
      kcHsTyVarBndrs, which was the outright bug reported in #11648.
      
      Test cases: polykinds/T11648{,b}
      
      This updates the haddock submodule.
      
      [skip ci]
      55577a91
  6. 26 Feb, 2016 1 commit
    • Simon Peyton Jones's avatar
      Exclude TyVars from the constraint solver · 7496be5c
      Simon Peyton Jones authored
      There is a general invariant that the constraint solver doesn't see
      TyVars, only TcTyVars.  But when checking the generic-default
      signature of a class, we called checkValidType on the generic-default
      type, which had the class TyVar free. That in turn meant that it wasn't
      considered during flattening, which led to the error reported in
      Trac #11608.
      
      The fix is simple: call checkValidType on the /closed/ type. Easy.
      
      While I was at it, I added a bunch of ASSERTs about the TcTyVar
      invariant.
      7496be5c
  7. 25 Feb, 2016 1 commit
    • barrucadu's avatar
      Print which warning-flag controls an emitted warning · bb5afd3c
      barrucadu authored
      Both gcc and clang tell which warning flag a reported warning can be
      controlled with, this patch makes ghc do the same. More generally, this
      allows for annotated compiler output, where an optional annotation is
      displayed in brackets after the severity.
      
      This also adds a new flag `-f(no-)show-warning-groups` to control
      whether to show which warning-group (such as `-Wall` or `-Wcompat`)
      a warning belongs to. This flag is on by default.
      
      This implements #10752
      
      Reviewed By: quchen, bgamari, hvr
      
      Differential Revision: https://phabricator.haskell.org/D1943
      bb5afd3c
  8. 24 Feb, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Address #11471 by putting RuntimeRep in kinds. · d8c64e86
      eir@cis.upenn.edu authored
      See Note [TYPE] in TysPrim. There are still some outstanding
      pieces in #11471 though, so this doesn't actually nail the bug.
      
      This commit also contains a few performance improvements:
      
      * Short-cut equality checking of nullary type syns
      
      * Compare types before kinds in eqType
      
      * INLINE coreViewOneStarKind
      
      * Store tycon binders separately from kinds.
      
      This resulted in a ~10% performance improvement in compiling
      the Cabal package. No change in functionality other than
      performance. (This affects the interface file format, though.)
      
      This commit updates the haddock submodule.
      d8c64e86
  9. 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
  10. 17 Feb, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Fix #11313. · a6152159
      eir@cis.upenn.edu authored
      Previously, we looked through synonyms when counting arguments,
      but that's a bit silly.
      a6152159
    • eir@cis.upenn.edu's avatar
      Fix #11246. · 489e6ab5
      eir@cis.upenn.edu authored
      We have to instantiate any invisible arguments to type families
      right away. This is now done in tcTyCon in TcHsType.
      
      testcase: typecheck/should_compile/T11246
      489e6ab5
  11. 10 Feb, 2016 1 commit
  12. 25 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Refactor validity checking for type/data instances · 746764cc
      Simon Peyton Jones authored
      I found that there was some code duplication going on,
      so I've put more into the shared function checkValidFamPats.
      
      I did some refactoring in checkConsistentFamInst too,
      preparatory to #11450; the error messages change a little
      but no change in behaviour.
      746764cc
  13. 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
  14. 19 Jan, 2016 2 commits
    • 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
    • Gabor Greif's avatar
      Typos in comments · 80265c4c
      Gabor Greif authored
      80265c4c
  15. 18 Jan, 2016 4 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
    • Simon Peyton Jones's avatar
      Refactoring on IdInfo and system derived names · ec8a188a
      Simon Peyton Jones authored
      Some modest refactoring, triggered in part by Trac #11051
      
      * Kill off PatSynId, ReflectionId in IdDetails
        They were barely used, and only for pretty-printing
      
      * Add helper function Id.mkExportedVanillaId, and use it
      
      * Polish up OccName.isDerivedOccName, as a predicate for
        definitions generated internally by GHC, which we
        might not want to show to the user.
      
      * Kill off unused OccName.mkDerivedTyConOcc
      
      * Shorten the derived OccNames for newtype and data
        instance axioms
      
      * A bit of related refactoring around newFamInstAxiomName
      ec8a188a
    • Simon Peyton Jones's avatar
      Fix typecheck of default associated type decls · cb24e684
      Simon Peyton Jones authored
      This bug was thrown up by Trac #11361, but I found that the
      problem was deeper: GHC was allowing
      
        class C a where
          type F (a :: k) :: *
          type F (x :: *) = x    -- Not right!
      
      (Which is now indexed-types/should_compile/T11361a.)
      
      Anyway the fix is relatively simple; use tcMatchTys in
      tcDefaultAssocDecl.
      
      Merge to 8.0 branch.
      cb24e684
    • Simon Peyton Jones's avatar
      Simplify API to tcMatchTys · 5a62b6ac
      Simon Peyton Jones authored
      Previously tcMatchTys took a set of "template type variables" to
      bind.  But all the calls are top-level, and we always want to
      bind all variables in the template.  So I simplified the API
      by omitting that argument.
      
      There should be no change in behaviour.
      
      Feel free to merge to 8.0 if it helps in merging other patches
      5a62b6ac
  16. 14 Jan, 2016 1 commit
  17. 09 Jan, 2016 1 commit
  18. 07 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Turn AThing into ATcTyCon, in TcTyThing · a5cea73c
      Simon Peyton Jones authored
      This change tidies up and simplifies (a bit) the knot-tying
      when kind-checking groups of type and class declarations.
      
      The trouble (shown by Trac #11356) was that we wanted an error message
      (a kind-mismatch) that involved a type mentioned a (AThing k), which
      blew up.
      
      Since we now seem to have TcTyCons, I decided to use them here.
      It's still not great, but it's easier to understand and more robust.
      a5cea73c
  19. 31 Dec, 2015 1 commit
  20. 24 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactoring only · 1af0d36b
      Simon Peyton Jones authored
      This moves code around to more sensible places.
      
      - Construction for CoAxiom is localised in FamInstEnv
      
      - orphNamesOfxx moves to CoreFVs
      
      - roughMatchTcs, instanceCantMatch moves to Unify
      
      - mkNewTypeCo moves from Coercion to FamInstEnv, and is
        renamed mkNewTypeCoAxiom, which makes more sense
      1af0d36b
  21. 23 Dec, 2015 1 commit
  22. 21 Dec, 2015 5 commits
  23. 15 Dec, 2015 2 commits
    • 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
    • Simon Peyton Jones's avatar
      Allow recursive (undecidable) superclasses · 6eabb6dd
      Simon Peyton Jones authored
      This patch fulfils the request in Trac #11067, #10318, and #10592,
      by lifting the conservative restrictions on superclass constraints.
      
      These restrictions are there (and have been since Haskell was born) to
      ensure that the transitive superclasses of a class constraint is a finite
      set.  However (a) this restriction is conservative, and can be annoying
      when there really is no recursion, and (b) sometimes genuinely recursive
      superclasses are useful (see the tickets).
      
      Dimitrios and I worked out that there is actually a relatively simple way
      to do the job. It’s described in some detail in
      
         Note [The superclass story] in TcCanonical
         Note [Expanding superclasses] in TcType
      
      In brief, the idea is to expand superclasses only finitely, but to
      iterate (using a loop that already existed) if there are more
      superclasses to explore.
      
      Other small things
      
      - I improved grouping of error messages a bit in TcErrors
      
      - I re-centred the haddock.compiler test, which was at 9.8%
        above the norm, and which this patch pushed slightly over
      6eabb6dd
  24. 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
  25. 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
  26. 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
  27. 27 Nov, 2015 1 commit
  28. 25 Nov, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor default methods (Trac #11105) · 924f8517
      Simon Peyton Jones authored
      This patch does some signficant refactoring to the treatment
      of default methods in class declarations, and more generally
      to the type checking of type/class decls.
      
      Highlights:
      
      * When the class has a generic-default method, such as
           class C a where
             op :: a -> a -> Bool
             default op :: Ord a => a -> a -> a
        the ClassOpItem records the type of the generic-default,
        in this case the type (Ord a => a -> a -> a)
      
      * I killed off Class.DefMeth in favour of the very-similar
        BasicTypes.DefMethSpec.  However it turned out to be better
        to use a Maybe, thus
            Maybe (DefMethSpec Type)
        with Nothing meaning "no default method".
      
      * In TcTyClsDecls.tcTyClGroup, we used to accumulate a [TyThing],
        but I found a way to make it much simpler, accumulating only
        a [TyCon].  Much less wrapping and unwrapping.
      
      * On the way I also fixed Trac #10896 in a better way. Instead
        of killing off all ambiguity checks whenever there are any type
        errors (the fix in commit 8e8b9ed9), I instead recover in
        TcTyClsDecls.checkValidTyCl.
      
      There was a lot of associated simplification all round
      924f8517