1. 07 Nov, 2016 1 commit
  2. 18 Sep, 2016 1 commit
    • Simon Peyton Jones's avatar
      Be less picky about reporing inaccessible code · 0e4e03a2
      Simon Peyton Jones authored
      Triggered by the discussion on Trac #12466, this patch
      makes GHC less aggressive about reporting an error when
      there are insoluble Givens.
      
      Being so agressive was making some libraries fail to
      compile, and is arguably wrong in at least some cases.
      See the discussion on the ticket.
      
      Several test now pass when they failed before; see
      the files-modified list for this patch.
      
      (cherry picked from commit 03541cba)
      0e4e03a2
  3. 25 Aug, 2016 2 commits
    • Simon Peyton Jones's avatar
      Expand given superclasses more eagerly · 0766668a
      Simon Peyton Jones authored
      This patch fixes Trac #12175, another delicate corner case of
      Note [Instance and Given overlap] in TcInteract.
      
      In #12175 we were not expanding given superclasses eagerly
      enough. It was easy to fix, and is actually rather neater than
      before.
      
      See Note [Eagerly expand given superclasses] in TcCanonical.
      The main change is to move the eager expansion of given superclasses
      to canClassNC.
      
      (cherry picked from commit ce97b729)
      0766668a
    • Simon Peyton Jones's avatar
      Keep the bindings local during defaultCallStacks · 829b9682
      Simon Peyton Jones authored
      defaultCallStacks generates evidence bindings for call stacks,
      but wasn't setting the binding site correctly.  As a result
      they were simply discarded in the case of pattern synonyms,
      giving rise to Trac #12489.
      
      The fix is easy; and I added an ASSERT to catch the error earlier.
      
      (cherry picked from commit f352e5cd)
      829b9682
  4. 24 Aug, 2016 1 commit
  5. 22 Aug, 2016 1 commit
  6. 25 Jul, 2016 5 commits
    • niteria's avatar
      Kill varSetElems try_tyvar_defaulting · e41984ce
      niteria authored
      `varSetElems` introduces unnecessary nondeterminism and we can do
      the same thing deterministically for the same price.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, simonmar, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2143
      
      GHC Trac Issues: #4012
      
      (cherry picked from commit 94320e1d)
      e41984ce
    • niteria's avatar
      Kill varSetElemsWellScoped in quantifyTyVars · f775c44a
      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
      
      (cherry picked from commit c9bcaf31)
      f775c44a
    • Simon Peyton Jones's avatar
      Fix two buglets in 17eb2419 noticed by Richard · 7c216d2a
      Simon Peyton Jones authored
      These are corner cases in
         17eb2419 Refactor computing dependent type vars
      and I couldn't even come up with a test case
      
      * In TcSimplify.simplifyInfer, in the promotion step, be sure
        to promote kind variables as well as type variables.
      
      * In TcType.spiltDepVarsOfTypes, the CoercionTy case, be sure
        to get the free coercion variables too.
      
      (cherry picked from commit 61191dee)
      7c216d2a
    • Simon Peyton Jones's avatar
      Refactor computing dependent type vars · 9f006295
      Simon Peyton Jones authored
      There should be no change in behaviour here
      
      * Move splitDepVarsOfType(s) from Type to TcType
      
      * Define data type TcType.TcDepVars, document what it means,
        and use it where appropriate, notably in splitDepVarsOfType(s)
      
      * Use it in TcMType.quantifyTyVars and friends
      
      (cherry picked from commit 17eb2419)
      9f006295
    • niteria's avatar
      Kill some unnecessary varSetElems · 7bfc8c03
      niteria authored
      When you do `varSetElems (tyCoVarsOfType x)` it's equivalent to
      `tyCoVarsOfTypeList x`.
      
      Why? If you look at the implementation:
      ```
      tyCoVarsOfTypeList ty = runFVList $ tyCoVarsOfTypeAcc ty
      tyCoVarsOfType ty = runFVSet $ tyCoVarsOfTypeAcc ty
      ```
      they use the same helper function. The helper function returns a
      deterministically ordered list and a set. The only difference
      between the two is which part of the result they take. It is redundant
      to take the set and then immediately convert it to a list.
      
      This helps with determinism and we eventually want to replace the uses
      of `varSetElems` with functions that don't leak the values of uniques.
      This change gets rid of some instances that are easy to kill.
      
      I chose not to annotate every place where I got rid of `varSetElems`
      with a comment about non-determinism, because once we get rid of
      `varSetElems` it will not be possible to do the wrong thing.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, simonmar, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D2115
      
      GHC Trac Issues: #4012
      
      (cherry picked from commit 928d7473)
      7bfc8c03
  7. 04 Apr, 2016 1 commit
    • Eric Seidel's avatar
      Don't infer CallStacks · 773e81ba
      Eric Seidel authored
      We originally wanted CallStacks to be opt-in, but dealing with let
      binders complicated things, forcing us to infer CallStacks. It turns
      out that the inference is actually unnecessary though, we can let the
      wanted CallStacks bubble up to the outer context by refusing to
      quantify over them. Eventually they'll be solved from a given CallStack
      or defaulted to the empty CallStack if they reach the top.
      
      So this patch prevents GHC from quantifying over CallStacks, getting us
      back to the original plan. There's a small ugliness to do with
      PartialTypeSignatures, if the partial theta contains a CallStack
      constraint, we *do* want to quantify over the CallStack; the user asked
      us to!
      
      Note that this means that
      
        foo :: _ => CallStack
        foo = getCallStack callStack
      
      will be an *empty* CallStack, since we won't infer a CallStack for the
      hole in the theta. I think this is the right move though, since we want
      CallStacks to be opt-in. One can always write
      
        foo :: (HasCallStack, _) => CallStack
        foo = getCallStack callStack
      
      to get the CallStack and still have GHC infer the rest of the theta.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, austin, hvr, bgamari
      
      Reviewed By: simonpj, bgamari
      
      Subscribers: bitemyapp, thomie
      
      Projects: #ghc
      
      Differential Revision: https://phabricator.haskell.org/D1912
      
      GHC Trac Issues: #11573
      
      (cherry picked from commit 7407a66d)
      773e81ba
  8. 24 Mar, 2016 1 commit
    • Rik Steenkamp's avatar
      Add `PatSynSigSkol` and modify `PatSynCtxt` · 13a54bc3
      Rik Steenkamp authored
      As the type of a pattern synonym cannot in general be represented by a
      value of type Type, we cannot use a value `SigSkol (PatSynCtxt n) (Check
      ty)` to represent the signature of a pattern synonym (this causes
      incorrect signatures to be printed in error messages). Therefore we now
      represent it by a value `PatSynSigSkol n` (instead of incorrect
      signatures we simply print no explicit signature).
      
      Furthermore, we rename `PatSynCtxt` to `PatSynBuilderCtxt`, and use
      `SigSkol (PatSynBuilderCtxt n) (Check ty)` to represent the type of a
      bidirectional pattern synonym when used in an expression context.
      Before, this type was represented by a value `SigSkol (PatSynCtxt n)
      (Check ty)`, which caused incorrect error messages.
      
      Also, in `mk_dict_err` of `typecheck\TcErrors.hs` we now distinguish
      between all enclosing implications and "useful" enclosing implications,
      for better error messages concerning pattern synonyms. See `Note [Useful
      implications]`.
      
      See the Phabricator page for examples.
      
      Reviewers: mpickering, goldfire, simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      Differential Revision: https://phabricator.haskell.org/D1967
      
      GHC Trac Issues: #11667
      
      (cherry picked from commit 997312b0)
      13a54bc3
  9. 23 Mar, 2016 2 commits
    • eir@cis.upenn.edu's avatar
      Zonk before calling splitDepVarsOfType. · f840006b
      eir@cis.upenn.edu authored
      It was Utterly Wrong before.
      
      Note to self: Never, ever take the free vars of an unzonked type.
      
      (cherry picked from commit 5c0c751a)
      f840006b
    • eir@cis.upenn.edu's avatar
      Fix #11711. · e3cf12ab
      eir@cis.upenn.edu authored
      There were two bugs here, both simple: we need to filter out
      covars before calling isMetaTyVar in the solver, and TcPat had
      a tcSubType the wrong way round.
      
      test case: dependent/should_compile/T11711
      
      (cherry picked from commit b5565f1a)
      e3cf12ab
  10. 13 Mar, 2016 1 commit
    • eir@cis.upenn.edu's avatar
      Address #11471 by putting RuntimeRep in kinds. · 223ef8db
      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.
      
      (cherry picked from commit d8c64e86)
      223ef8db
  11. 28 Feb, 2016 1 commit
    • barrucadu's avatar
      Print which warning-flag controls an emitted warning · 4f5b7ad8
      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
      
      (cherry picked from commit bb5afd3c)
      4f5b7ad8
  12. 11 Feb, 2016 2 commits
    • Simon Peyton Jones's avatar
      Wrap solveEqualities in checkNoErrs · d0010d74
      Simon Peyton Jones authored
      This simple change fixes Trac #11563, #11520, #11516, #11399.
      See esp the comments in #11520.
      
      See Note [Fail fast on kind errors] in TcSimplify
      
      Merge to 8.0 branch
      
      (cherry picked from commit b565830d)
      d0010d74
    • Simon Peyton Jones's avatar
      Improve error messages for recursive superclasses · 4916993c
      Simon Peyton Jones authored
      If we fail to typecheck by blowing the constraint simplifier
      iteration limit, we want to see the limit-blowing meessage.
      Previously it was being suppressed by the type /error/, which
      suppress the iteration-limit /warning/.  Solution: make the
      iteration-limit message into an error.
      
      (cherry picked from commit d6b68be1)
      4916993c
  13. 25 Jan, 2016 1 commit
    • Simon Peyton Jones's avatar
      Special-case implicit params in superclass expansion · 6217147e
      Simon Peyton Jones authored
      This issue came up in Trac #11480, and is documented in
      Note [When superclasses help] in TcRnTypes.
      
      We were getting a spurious warning
        T11480.hs:1:1: warning:
           solveWanteds: too many iterations (limit = 4)
      
      The fix is easy.  A bit of refactoring along the way.
      
      The original bug report in Trac #11480 appears to work
      fine in HEAD and the 8.0 branch but I added a regression
      test in this commit as well.
      
      (cherry picked from commit ff21795a)
      6217147e
  14. 22 Jan, 2016 1 commit
  15. 21 Jan, 2016 1 commit
  16. 19 Jan, 2016 1 commit
    • Jan Stolarek's avatar
      Replace calls to `ptext . sLit` with `text` · f02fefd3
      Jan Stolarek authored
      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
      
      (cherry picked from commit b8abd852)
      f02fefd3
  17. 18 Jan, 2016 2 commits
    • Simon Peyton Jones's avatar
      Improve debug printing/warnings · 00b64a5d
      Simon Peyton Jones authored
      (cherry picked from commit 6e0c0fd2)
      00b64a5d
    • Simon Peyton Jones's avatar
      Simplify API to tcMatchTys · 8e6ec665
      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
      
      (cherry picked from commit 5a62b6ac)
      8e6ec665
  18. 18 Dec, 2015 1 commit
    • Simon Peyton Jones's avatar
      tcCheckSatisfiability: less aggressive superclass expansion · ff752a1a
      Simon Peyton Jones authored
      In the pattern-match check we are looking for a proof of
      *unsatisfiablity* among a bunch of givens.  The unsat-ness might be
      hidden in the superclasses, so we must expand them.  But in the common
      case where the constraints are satisfiable, we don't want to expand
      a recursive superclass forever.
      
      This is all a bit arbitrary, but then the whole question is
      undecidable anyway.
      
      The bug in Trac #10592 comment:12 was that I expanded superclasses
      forever.  This patch fixes it.
      ff752a1a
  19. 16 Dec, 2015 1 commit
    • quchen's avatar
      Add `-W(no-)xxx` aliases for `-f(no-)warn-xxx` flags · 2206fa8c
      quchen authored
      This also updates the user's guide to refer to the `-W`-based warning
      flags by default.
      
      Quoting the release note entry:
      
      | Warnings can now be controlled with `-W(no-)...` flags in addition to
      | the old `-f(no-)warn...` ones. This was done as the first part of a
      | rewrite of the warning system to provide better control over warnings,
      | better warning messages, and more common syntax compared to other
      | compilers. The old `-fwarn...`-based warning flags will remain
      | functional for the forseeable future.
      
      This is part of
      https://ghc.haskell.org/wiki/Design/Warnings
      and addresses #11218
      
      Reviewed By: hvr, bgamari
      
      Differential Revision: https://phabricator.haskell.org/D1613
      2206fa8c
  20. 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
  21. 14 Dec, 2015 1 commit
  22. 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
  23. 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
  24. 04 Dec, 2015 1 commit
  25. 03 Dec, 2015 1 commit
    • Georgios Karachalias's avatar
      Major Overhaul of Pattern Match Checking (Fixes #595) · 8a506104
      Georgios Karachalias authored
      This patch adresses several problems concerned with exhaustiveness and
      redundancy checking of pattern matching. The list of improvements includes:
      
      * Making the check type-aware (handles GADTs, Type Families, DataKinds, etc.).
        This fixes #4139, #3927, #8970 and other related tickets.
      
      * Making the check laziness-aware. Cases that are overlapped but affect
        evaluation are issued now with "Patterns have inaccessible right hand side".
        Additionally, "Patterns are overlapped" is now replaced by "Patterns are
        redundant".
      
      * Improved messages for literals. This addresses tickets #5724, #2204, etc.
      
      * Improved reasoning concerning cases where simple and overloaded
        patterns are matched (See #322).
      
      * Substantially improved reasoning for pattern guards. Addresses #3078.
      
      * OverloadedLists extension does not break exhaustiveness checking anymore
        (addresses #9951). Note that in general this cannot be handled but if we know
        that an argument has type '[a]', we treat it as a list since, the instance of
        'IsList' gives the identity for both 'fromList' and 'toList'. If the type is
        not clear or is not the list type, then the check cannot do much still. I am
        a bit concerned about OverlappingInstances though, since one may override the
        '[a]' instance with e.g. an '[Int]' instance that is not the identity.
      
      * Improved reasoning for nested pattern matching (partial solution). Now we
        propagate type and (some) term constraints deeper when checking, so we can
        detect more inconsistencies. For example, this is needed for #4139.
      
      I am still not satisfied with several things but I would like to address at
      least the following before the next release:
          Term constraints are too many and not printed for non-exhaustive matches
      (with the exception of literals). This sometimes results in two identical (in
      appearance) uncovered warnings. Unless we actually show their difference, I
      would like to have a single warning.
      8a506104
  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. 20 Oct, 2015 1 commit
  28. 13 Oct, 2015 1 commit
  29. 12 Oct, 2015 1 commit
    • Simon Peyton Jones's avatar
      Reinstate monomorphism-restriction warnings · f8fbf385
      Simon Peyton Jones authored
      This patch is driven by Trac #10935, and reinstates the
      -fwarn-monomorphism-restriction warning.  It was first lost in 2010:
      d2ce0f52 "Super-monster patch implementing the new typechecker -- at
      last"
      
      I think the existing documentation is accurate; it is not even
      turned on by -Wall.
      
      I added one test.
      f8fbf385
  30. 06 Aug, 2015 1 commit
  31. 05 Aug, 2015 1 commit
    • 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