1. 18 Jan, 2016 1 commit
    • 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
  2. 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
  3. 22 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      Refactor named wildcards (again) · 575a98e4
      Simon Peyton Jones authored
      Michal's work on #10982, #11098, refactored the handling of named
      wildcards by making them more like ordinary type variables.
      
      This patch takes the same idea to its logical conclusion, resulting
      in a much tidier, tighter implementation.
      
      Read Note [The wildcard story for types] in HsTypes.
      
      Changes:
      
       * Named wildcards are ordinary type variables, throughout
      
       * HsType no longer has a data constructor for named wildcards
         (was NamedWildCard in HsWildCardInfo).  Named wildcards are
         simply HsTyVars
      
       * Similarly named wildcards disappear from Template Haskell
      
       * I refactored RnTypes to avoid polluting LocalRdrEnv with something
         as narrow as named wildcards.  Instead the named wildcard set is
         carried in RnTyKiEnv.
      
      There is a submodule update for Haddock.
      575a98e4
  4. 21 Dec, 2015 1 commit
    • msosn's avatar
      Warn about unused type variables in type families · eb7796f1
      msosn authored
      The warnings are enabled with the flag -fwarn-unused-matches, the same
      one that enables warnings on the term level.
      
      Identifiers starting with an underscore are now always parsed as type
      variables.  When the NamedWildCards extension is enabled, the renamer
      replaces those variables with named wildcards.
      
      An additional NameSet nwcs is added to LocalRdrEnv. It's used to keep
      names of the type variables that should be replaced with wildcards.
      
      While renaming HsForAllTy, when a name is explicitly bound it is removed
      from the nwcs NameSet. As a result, the renamer doesn't replace them in
      the quantifier body. (Trac #11098)
      
      Fixes #10982, #11098
      
      Reviewers: alanz, bgamari, hvr, austin, jstolarek
      
      Reviewed By: jstolarek
      
      Subscribers: goldfire, mpickering, RyanGlScott, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1576
      
      GHC Trac Issues: #10982
      eb7796f1
  5. 18 Dec, 2015 1 commit
  6. 15 Dec, 2015 2 commits
    • 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
    • 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...
      6eabb6dd
  7. 12 Dec, 2015 1 commit
    • Eric Seidel's avatar
      Rework the Implicit CallStack solver to handle local lets. · 3ec8288a
      Eric Seidel authored
      We can't just solve CallStack constraints indiscriminately when they
      occur in the RHS of a let-binder. The top-level given CallStack (if
      any) will not be in scope, so I've re-worked the CallStack solver as
      follows:
      
      1. CallStacks are treated like regular IPs unless one of the following
         two rules apply.
      
      2. In a function call, we push the call-site onto a NEW wanted
         CallStack, which GHC will solve as a regular IP (either directly from a
         given, or by quantifying over it in a local let).
      
      3. If, after the constraint solver is done, any wanted CallStacks
         remain, we default them to the empty CallStack. This rule exists mainly
         to clean up after rule 2 in a top-level binder with no given CallStack.
      
      In rule (2) we have to be careful to emit the new wanted with an
      IPOccOrigin instead of an OccurrenceOf origin, so rule (2) doesn't fire
      again. This is a bit shady but I've updated the Note to explain the
      trick.
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari, hvr
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1422
      
      GHC Trac Issues: #10845
      3ec8288a
  8. 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
  9. 10 Dec, 2015 1 commit
  10. 04 Dec, 2015 1 commit
  11. 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
  12. 24 Nov, 2015 1 commit
    • elaforge's avatar
      Rearrange error msgs and add section markers (Trac #11014). · c05fddde
      elaforge authored
      This puts the "Relevant bindings" section at the end.
      
      It uses a TcErrors.Report Monoid to divide messages by importance and
      then mappends them together.  This is not the most efficient way since
      there are various intermediate Reports and list appends, but it probably
      doesn't matter since error messages shouldn't get that large, and are
      usually prepended.  In practice, everything is `important` except
      `relevantBindings`, which is `supplementary`.
      
      ErrMsg's errMsgShortDoc and errMsgExtraInfo were extracted into ErrDoc,
      which has important, context, and suppelementary fields.  Each of those
      three sections is marked with a bullet character, '•' on unicode
      terminals and '*' on ascii terminals.  Since this breaks tons of tests,
      I also modified testlib.normalise_errmsg to strip out '•'s.
      
      --- Additional notes:
      
      To avoid prepending * to an empty doc, I needed to filter empty docs.
      This seemed less error-prone than trying to modify everyone who produces
      SDoc to instead produce Maybe SDoc.  So I added `Outputable.isEmpty`.
      Unfortunately it needs a DynFlags, which is kind of bogus, but otherwise
      I think I'd need another Empty case for SDoc, and then it couldn't be a
      newtype any more.
      
      ErrMsg's errMsgShortString is only used by the Show instance, which is
      in turn only used by Show HscTypes.SourceError, which is in turn only
      needed for the Exception instance.  So it's probably possible to get rid
      of errMsgShortString, but that would a be an unrelated cleanup.
      
      Fixes #11014.
      
      Test Plan: see above
      
      Reviewers: austin, simonpj, thomie, bgamari
      
      Reviewed By: thomie, bgamari
      
      Subscribers: simonpj, nomeata, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1427
      
      GHC Trac Issues: #11014
      c05fddde
  13. 21 Nov, 2015 1 commit
    • niteria's avatar
      Create a deterministic version of tyVarsOfType · 2325bd4e
      niteria authored
      I've run into situations where I need deterministic `tyVarsOfType` and
      this implementation achieves that and also brings an algorithmic
      improvement.  Union of two `VarSet`s takes linear time the size of the
      sets and in the worst case we can have `n` unions of sets of sizes
      `(n-1, 1), (n-2, 1)...` making it quadratic.
      
      One reason why we need deterministic `tyVarsOfType` is in `abstractVars`
      in `SetLevels`. When we abstract type variables when floating we want
      them to be abstracted in deterministic order.
      
      Test Plan: harbormaster
      
      Reviewers: simonpj, goldfire, austin, hvr, simonmar, bgamari
      
      Reviewed By: simonmar
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1468
      
      GHC Trac Issues: #4012
      2325bd4e
  14. 18 Nov, 2015 1 commit
    • msosn's avatar
      Fix inconsistent pretty-printing of type families · c61759d5
      msosn authored
      After the changes, the three functions used to print type families
      were identical, so they are refactored into one.
      
      Original RHSs of data instance declarations are recreated and
      printed in user error messages.
      
      RHSs containing representation TyCons are printed in the
      Coercion Axioms section in a typechecker dump.
      
      Add vbar to the list of SDocs exported by Outputable.
      Replace all text "|" docs with it.
      
      Fixes #10839
      
      Reviewers: goldfire, jstolarek, austin, bgamari
      
      Reviewed By: jstolarek
      
      Subscribers: jstolarek, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1441
      
      GHC Trac Issues: #10839
      c61759d5
  15. 07 Nov, 2015 1 commit
    • Simon Marlow's avatar
      Make GHCi & TH work when the compiler is built with -prof · ce1f1607
      Simon Marlow authored
      Summary:
      Amazingly, there were zero changes to the byte code generator and very
      few changes to the interpreter - mainly because we've used good
      abstractions that hide the differences between profiling and
      non-profiling.  So that bit was pleasantly straightforward, but there
      were a pile of other wibbles to get the whole test suite through.
      
      Note that a compiler built with -prof is now like one built with
      -dynamic, in that to use TH you have to build the code the same way.
      For dynamic, we automatically enable -dynamic-too when TH is required,
      but we don't have anything equivalent for profiling, so you have to
      explicitly use -prof when building code that uses TH with a profiled
      compiler.  For this reason Cabal won't work with TH.  We don't expect
      to ship a profiled compiler, so I think that's OK.
      
      Test Plan: validate with GhcProfiled=YES in validate.mk
      
      Reviewers: goldfire, bgamari, rwbarton, austin, hvr, erikd, ezyang
      
      Reviewed By: ezyang
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1407
      
      GHC Trac Issues: #4837, #545
      ce1f1607
  16. 01 Nov, 2015 2 commits
    • Herbert Valerio Riedel's avatar
      Bump ghc-prim version to 0.5.0.0 (closes #11043) · 84bf1eba
      Herbert Valerio Riedel authored
      This also needs to update the primitive/vector submodules in order to
      relax upper bounds on ghc-prim.
      
      Like in f8ba4b55, a mass-rewrite in testsuite/ via
      
        sed -i s,ghc-prim-0.4.0.0,ghc-prim-0.5.0.0,g $(git grep -Fl 'ghc-prim-0.4.0.0')
      
      was performed.
      84bf1eba
    • 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
  17. 30 Oct, 2015 1 commit
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · 91c6b1f5
      Ben Gamari authored
      This is the second attempt at merging D757.
      
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing
      stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T1969:    GHC allocates 19% more
       * T4801:    GHC allocates 13% more
       * T5321FD:  GHC allocates 13% more
       * T9675:    GHC allocates 11% more
       * T783:     GHC allocates 11% more
       * T5642:    GHC allocates 10% more
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might
      be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I
      have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Updates haddock submodule
      
      Test Plan: Let Harbormaster validate
      
      Reviewers: austin, hvr, goldfire
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1404
      
      GHC Trac Issues: #9858
      91c6b1f5
  18. 29 Oct, 2015 2 commits
    • Ben Gamari's avatar
      Revert "Generate Typeable info at definition sites" · bbaf76f9
      Ben Gamari authored
      This reverts commit bef2f03e.
      
      This merge was botched
      
      Also reverts haddock submodule.
      bbaf76f9
    • Ben Gamari's avatar
      Generate Typeable info at definition sites · bef2f03e
      Ben Gamari authored
      This patch implements the idea floated in Trac #9858, namely that we
      should generate type-representation information at the data type
      declaration site, rather than when solving a Typeable constraint.
      
      However, this turned out quite a bit harder than I expected. I still
      think it's the right thing to do, and it's done now, but it was quite
      a struggle.
      
      See particularly
      
       * Note [Grand plan for Typeable] in TcTypeable (which is a new module)
       * Note [The overall promotion story] in DataCon (clarifies existing stuff)
      
      The most painful bit was that to generate Typeable instances (ie
      TyConRepName bindings) for every TyCon is tricky for types in ghc-prim
      etc:
      
       * We need to have enough data types around to *define* a TyCon
       * Many of these types are wired-in
      
      Also, to minimise the code generated for each data type, I wanted to
      generate pure data, not CAFs with unpackCString# stuff floating about.
      
      Performance
      ~~~~~~~~~~~
      Three perf/compiler tests start to allocate quite a bit more. This isn't
      surprising, because they all allocate zillions of data types, with
      practically no other code, esp. T1969
      
       * T3294:   GHC allocates 110% more (filed #11030 to track this)
       * T1969:   GHC allocates 30% more
       * T4801:   GHC allocates 14% more
       * T5321FD: GHC allocates 13% more
       * T783:    GHC allocates 12% more
       * T9675:   GHC allocates 12% more
       * T5642:   GHC allocates 10% more
       * T9961:   GHC allocates 6% more
      
       * T9203:   Program allocates 54% less
      
      I'm treating this as acceptable. The payoff comes in Typeable-heavy
      code.
      
      Remaining to do
      ~~~~~~~~~~~~~~~
      
       * I think that "TyCon" and "Module" are over-generic names to use for
         the runtime type representations used in GHC.Typeable. Better might be
         "TrTyCon" and "TrModule". But I have not yet done this
      
       * Add more info the the "TyCon" e.g. source location where it was
         defined
      
       * Use the new "Module" type to help with Trac Trac #10068
      
       * It would be possible to generate TyConRepName (ie Typeable
         instances) selectively rather than all the time. We'd need to persist
         the information in interface files. Lacking a motivating reason I have
         not done this, but it would not be difficult.
      
      Refactoring
      ~~~~~~~~~~~
      As is so often the case, I ended up refactoring more than I intended.
      In particular
      
       * In TyCon, a type *family* (whether type or data) is repesented by a
         FamilyTyCon
           * a algebraic data type (including data/newtype instances) is
             represented by AlgTyCon This wasn't true before; a data family
             was represented as an AlgTyCon. There are some corresponding
             changes in IfaceSyn.
      
           * Also get rid of the (unhelpfully named) tyConParent.
      
       * In TyCon define 'Promoted', isomorphic to Maybe, used when things are
         optionally promoted; and use it elsewhere in GHC.
      
       * Cleanup handling of knownKeyNames
      
       * Each TyCon, including promoted TyCons, contains its TyConRepName, if
         it has one. This is, in effect, the name of its Typeable instance.
      
      Requires update of the haddock submodule.
      
      Differential Revision: https://phabricator.haskell.org/D757
      bef2f03e
  19. 27 Oct, 2015 2 commits
  20. 05 Aug, 2015 2 commits
    • Simon Peyton Jones's avatar
      Fix quantification for inference with sigs · 28096b27
      Simon Peyton Jones authored
      When we are *inferring* the type of a let-bound function,
      we might still have a type signature.  And we must be sure
      to quantify over its type variables, else you get the crash
      in Trac #10615.
      
      See Note [Which type variables to quantify] in TcSimplify
      28096b27
    • 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
  21. 03 Aug, 2015 1 commit
    • thomasw's avatar
      Support wild cards in data/type family instances · d9d2102e
      thomasw authored
      Handle anonymous wild cards in type or data family instance
      declarations like
      unnamed type variables. For instance (pun intented):
      
          type family F (a :: *) (b :: *) :: *
          type instance F Int _ = Int
      
      Is now the same as:
      
          type family F (a :: *) (b :: *) :: *
          type instance F Int x = Int
      
      Note that unlike wild cards in partial type signatures, no errors (or
      warnings
      with -XPartialTypeSignatures) are generated for these wild cards, as
      there is
      nothing interesting to report to the user, i.e. the inferred kind.
      
      Only anonymous wild cards are supported here, named and
      extra-constraints wild
      card are not.
      
      Test Plan: pass new tests
      
      Reviewers: goldfire, austin, simonpj, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: goldfire, thomie
      
      Differential Revision: https://phabricator.haskell.org/D1092
      
      GHC Trac Issues: #3699, #10586
      d9d2102e
  22. 30 Jul, 2015 1 commit
    • Simon Peyton Jones's avatar
      Better treatment of signatures in cls/inst · 72d23c3e
      Simon Peyton Jones authored
      The provoking cause for this patch is Trac #5001, comment:23.  There
      was an INLINE pragma in an instance decl, that shouldn't be there.
      But there was no complaint, just a  mysterious WARN later.
      
      I ended up having to do some real refactoring but the result is,
      I think, simpler and more robust.
      72d23c3e
  23. 20 Jul, 2015 1 commit
    • thomasw's avatar
      Support wild cards in TH splices · 49373ffe
      thomasw authored
      - Declaration splices: partial type signatures are fully supported in TH
        declaration splices.
      
        For example, the wild cards in the example below will unify with `Eq
      a`
        and `a -> a -> Bool`, as expected:
      
      ```
      [d| foo :: _ => _
          foo x y = x == y |]
      ```
      
      - Expression splices: anonymous and named wild cards are supported in
        expression signatures, but extra-constraints wild cards aren't. Just
        as is the case for regular expression signatures.
      
      ```
      [e | Just True :: _a _ |]
      ```
      
      - Typed expression splices: the same wildcards as in (untyped)
        expression splices are supported.
      
      - Pattern splices: TH doesn't support type signatures in pattern
        splices, consequently, partial type signatures aren't supported
        either.
      
      - Type splices: partial type signatures are only partially supported in
        type splices, specifically: only anonymous wild cards are allowed.
      
        So `[t| _ |]`, `[t| _ -> Maybe _ |]` will work, but `[t| _ => _ |]` or
        `[| _a |]` won't (without `-XNamedWildCards`, the latter will work as
        the named wild card is treated as a type variable).
      
        Normally, named wild cards are collected before renaming a (partial)
        type signature. However, TH type splices are run during renaming, i.e.
        after the initial traversal, leading to out of scope errors for named
        wild cards. We can't just extend the initial traversal to collect the
        named wild cards in TH type splices, as we'd need to expand them,
        which is supposed to happen only once, during renaming.
      
        Similarly, the extra-constraints wild card is handled right before
        renaming too, and is therefore also not supported in a TH type splice.
        Another reason not to support extra-constraints wild cards in TH type
        splices is that a single signature can contain many TH type splices,
        whereas it mustn't contain more than one extra-constraints wild card.
        Enforcing would this be hard the way things are currently organised.
      
        Anonymous wild cards pose no problem, because they start without names
        and are given names during renaming. These names are collected right
        after renaming. The names generated for anonymous wild cards in TH
        type splices will thus be collected as well.
      
        With a more invasive refactoring of the renaming, partial type
        signatures could be fully supported in TH type splices. As only
        anonymous wild cards have been requested so far, these small changes
        satisfying this request will do for now. Also don't forget that a TH
        declaration splices support all kinds of wild cards.
      
      - Extra-constraints wild cards were silently ignored in expression and
        pattern signatures, appropriate error messages are now generated.
      
      Test Plan: run new tests
      
      Reviewers: austin, goldfire, adamgundry, bgamari
      
      Reviewed By: goldfire, adamgundry, bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1048
      
      GHC Trac Issues: #10094, #10548
      49373ffe
  24. 13 Jul, 2015 2 commits
  25. 10 Jul, 2015 1 commit
  26. 03 Jul, 2015 1 commit
    • thomasw's avatar
      Fix Trac #10519 · f8563838
      thomasw authored
      Look through nested foralls when checking the validity of a partial type
      signature. The combination of D836 and D613 prompts this change.
      
      Test Plan: The test T10519 must pass
      
      Reviewers: simonpj, alanz, austin
      
      Reviewed By: simonpj, alanz, austin
      
      Subscribers: thomie, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D994
      
      GHC Trac Issues: #10519
      f8563838
  27. 26 Jun, 2015 2 commits
  28. 23 Jun, 2015 1 commit
  29. 18 Jun, 2015 1 commit
  30. 11 Jun, 2015 1 commit
    • thomie's avatar
      Testsuite: change some expect_fail tests to expect_broken · 5e66a698
      thomie authored
      Change the following tests from expect_fail to expect_broken: and list
      the ticket number:
      
          * driver/sigof03m/sigof03 (#9252)
          * driver/static001 (#8127)
          * partial-sigs/should_compile/EqualityConstraint (#9478)
          * partial-sigs/should_compile/ExtraNumAMROn (#9478)
          * partial-sigs/should_compile/PatBind2 (#9478)
          * partial-sigs/should_fail/TidyClash2 (#9478)
          * simplCore/should_compile/T8832 (#8832)
      
      The following tests are still marked as expect_fail, but it is not
      clearly documented why so:
      
          * gadt/lazypatok
          * indexed-types/should_fail/SkolemOccursLoop
      
      All other expect_fail tests are only expected to fail on either a
      certain platform/os or for a certain way only.
      
      Differential Revision: https://phabricator.haskell.org/D966
      5e66a698
  31. 09 Jun, 2015 1 commit
    • thomasw's avatar
      Refactor wild card renaming · 058af6c9
      thomasw authored
      Summary:
      Refactor wild card error reporting
      
      * Merge `HsWildcardTy` and `HsNamedWildcardTy` into one constructor
        `HsWildCardTy` with as field the new type `HsWildCardInfo`, which has two
        constructors: `AnonWildCard` and `NamedWildCard`.
      
      * All partial type checks are removed from `RdrHsSyn.hs` and are now done
        during renaming in order to report better error messages. When wild cards
        are allowed in a type, the new function `rnLHsTypeWithWildCards` (or
        `rnHsSigTypeWithWildCards`) should be used. This will bring the named wild
        cards into scope before renaming them. When this is not done, renaming will
        trigger "Unexpected wild card..." errors.
      
        Unfortunately, this has to be done separately for anonymous wild cards
        because they are given a fresh name during renaming, so they will not cause
        an out-of-scope error. They are handled in `tc_hs_type`, as a special case
        of a lookup that fails.
      
        The previous opt-out approach is replaced with an opt-in approach. No more
        panics because of forgotten checks!
      
      * `[t| _ |]` isn't caught by the above two checks, so it is currently handled
        by a special case. The error message (generated in the `DsM` monad) doesn't
        provide as much context information as the other cases.
      
      * Instead of three (!) functions that walk `HsType`, there is now only one
        pure function called `collectWildCards`.
      
      * Alternative approach: catch all unwanted wild cards in `rnHsTyKi` by looking
        at the `HsDocContext`. This will reduce the number of places to catch
        unwanted wild cards form three to one, and make the error messages more
        uniform, albeit less informative, as the error context for renaming is not
        as informative as the one for type checking. A new constructor of
        `HsDocContext` will be required for pattern synonyms signatures.
      
        Small problem: currently type-class type signatures can't be distinguished
        from type signatures using the `HsDocContext`.
      
      This requires an update to the Haddock submodule.
      
      Test Plan: validate
      
      Reviewers: goldfire, simonpj, austin
      
      Reviewed By: simonpj
      
      Subscribers: bgamari, thomie, goldfire
      
      Differential Revision: https://phabricator.haskell.org/D613
      
      GHC Trac Issues: #10098
      058af6c9
  32. 02 Jun, 2015 1 commit
  33. 18 May, 2015 1 commit