1. 22 Jul, 2018 1 commit
  2. 12 Jul, 2018 2 commits
  3. 06 Jul, 2018 1 commit
    • Michael Sloan's avatar
      Add a broken test for lingering state from TH unique names #9693 · fbe162f5
      Michael Sloan authored
      The stderr output is
      
      ```
      Loading with T9693_initial.hs
      
      T9693_main.hs:4:1:
          Same exact name in multiple name-spaces:
            type constructor or class ‘X’, declared at: T9693_main.hs:4:1
            data constructor ‘X’, declared at: T9693_main.hs:4:1
            Probable cause: you bound a unique Template Haskell name (NameU),
            perhaps via newName, in different name-spaces.
            If that's it, then -ddump-splices might be useful
      Reloading with T9693_modified.hs
      
      T9693_main.hs:1:1:
          Data constructor ‘X’ used as a type constructor
      ```
      
      The strange thing is that the modified version uses (mkName "X"), which should
      be fine for simultaneous use in both a data constructor and type constructor.
      Indeed, on a fresh load, the modified version works fine. So there is some sort
      of state left over from the prior load when (newName "X") was used.
      
      Test Plan: testsuite/tests/th/T9693.script
      
      Reviewers: bgamari, sighingnow, RyanGlScott
      
      Reviewed By: sighingnow, RyanGlScott
      
      Subscribers: RyanGlScott, sighingnow, rwbarton, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4926
      fbe162f5
  4. 05 Jul, 2018 2 commits
  5. 04 Jul, 2018 1 commit
  6. 10 Jun, 2018 1 commit
  7. 07 Jun, 2018 1 commit
    • Ryan Scott's avatar
      Fix #15243 by fixing incorrect uses of NotPromoted · 569c16a7
      Ryan Scott authored
      In `Convert`, we were incorrectly using `NotPromoted` to
      denote type constructors that were actually intended to be promoted,
      resulting in poor `-ddump-splices` output (as seen in #15243).
      Easily fixed.
      
      Test Plan: make test TEST=T15243
      
      Reviewers: bgamari, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #15243
      
      Differential Revision: https://phabricator.haskell.org/D4809
      569c16a7
  8. 30 May, 2018 1 commit
    • Matthías Páll Gissurarson's avatar
      Improved Valid Hole Fits · e0b44e2e
      Matthías Páll Gissurarson authored
      I've changed the name from `Valid substitutions` to `Valid hole fits`,
      since "substitution" already has a well defined meaning within the
      theory. As part of this change, the flags and output is reanamed, with
      substitution turning into hole-fit in most cases. "hole fit" was already
      used internally in the code, it's clear and shouldn't cause any
      confusion.
      
      In this update, I've also reworked how we manage side-effects in the
      hole we are considering.
      
      This allows us to consider local bindings such as where clauses and
      arguments to functions, suggesting e.g. `a` for `head (x:xs) where head
      :: [a] -> a`.
      
      It also allows us to find suggestions such as `maximum` for holes of
      type `Ord a => a -> [a]`, and `max` when looking for a match for the
      hole in `g = foldl1 _`, where `g :: Ord a => [a] -> a`.
      
      We also show much improved output for refinement hole fits, and
      fixes #14990. We now show the correct type of the function, but we also
      now show what the arguments to the function should be e.g. `foldl1 (_ ::
      Integer -> Integer -> Integer)` when looking for `[Integer] -> Integer`.
      
      I've moved the bulk of the code from `TcErrors.hs` to a new file,
      `TcHoleErrors.hs`, since it was getting too big to not live on it's own.
      
      This addresses the considerations raised in #14969, and takes proper
      care to set the `tcLevel` of the variables to the right level before
      passing it to the simplifier.
      
      We now also zonk the suggestions properly, which improves the output of
      the refinement hole fits considerably.
      
      This also filters out suggestions from the `GHC.Err` module, since even
      though `error` and `undefined` are indeed valid hole fits, they are
      "trivial", and almost never useful to the user.
      
      We now find the hole fits using the proper manner, namely by solving
      nested implications. This entails that the givens are passed along using
      the implications the hole was nested in, which in turn should mean that
      there will be fewer weird bugs in the typed holes.
      
      I've also added a new sorting method (as suggested by SPJ) and sort by
      the size of the types needed to turn the hole fits into the type of the
      hole. This gives a reasonable approximation to relevance, and is much
      faster than the subsumption check. I've also added a flag to toggle
      whether to use this new sorting algorithm (as is done by default) or the
      subsumption algorithm. This fixes #14969
      
      I've also added documentation for these new flags and update the
      documentation according to the new output.
      
      Reviewers: bgamari, goldfire
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14969, #14990, #10946
      
      Differential Revision: https://phabricator.haskell.org/D4444
      e0b44e2e
  9. 24 May, 2018 1 commit
    • Ryan Scott's avatar
      Check for mismatched class methods during typechecking · 1879d9d2
      Ryan Scott authored
      Summary:
      Template Haskell provides a wormhole through which you can
      sneak methods that don't belong to a class into an instance for that
      class, bypassing the renamer's validity checks. The solution adopted
      here is to mirror the treatment for associated type family instances,
      which have an additional check in the typechecker which catch
      mismatched associated type families that were snuck through using
      Template Haskell. I've put a similar check for class methods into
      `tcMethods`.
      
      Test Plan: make test TEST=T12387
      
      Reviewers: bgamari, simonpj
      
      Reviewed By: bgamari, simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #12387
      
      Differential Revision: https://phabricator.haskell.org/D4710
      1879d9d2
  10. 20 May, 2018 1 commit
  11. 14 May, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14875 by introducing PprPrec, and using it · 21e1a00c
      Ryan Scott authored
      Trying to determine when to insert parentheses during TH
      conversion is a bit of a mess. There is an assortment of functions
      that try to detect this, such as:
      
      * `hsExprNeedsParens`
      * `isCompoundHsType`
      * `hsPatNeedsParens`
      * `isCompoundPat`
      * etc.
      
      To make things worse, each of them have slightly different semantics.
      Plus, they don't work well in the presence of explicit type
      signatures, as #14875 demonstrates.
      
      All of these problems can be alleviated with the use of an explicit
      precedence argument (much like what `showsPrec` currently does). To
      accomplish this, I introduce a new `PprPrec` data type, and define
      standard predences for things like function application, infix
      operators, function arrows, and explicit type signatures (that last
      one is new). I then added `PprPrec` arguments to the various
      `-NeedsParens` functions, and use them to make smarter decisions
      about when things need to be parenthesized.
      
      A nice side effect is that functions like `isCompoundHsType` are
      now completely unneeded, since they're simply aliases for
      `hsTypeNeedsParens appPrec`. As a result, I did a bit of refactoring
      to remove these sorts of functions. I also did a pass over various
      utility functions in GHC for constructing AST forms and used more
      appropriate precedences where convenient.
      
      Along the way, I also ripped out the existing `TyPrec`
      data type (which was tailor-made for pretty-printing `Type`s) and
      replaced it with `PprPrec` for consistency.
      
      Test Plan: make test TEST=T14875
      
      Reviewers: alanz, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14875
      
      Differential Revision: https://phabricator.haskell.org/D4688
      21e1a00c
  12. 19 Apr, 2018 1 commit
  13. 10 Apr, 2018 1 commit
  14. 25 Mar, 2018 2 commits
    • Tao He's avatar
      Fix scoped type variables in TH for several constructs · a3986d7f
      Tao He authored
      Namely class methods, default signatures and pattern synonyms.
      
      When scoped type variables occur inside class default methods,
      default signatures and pattern synonyms, avoid re-create explicit
      type variables when represent the type signatures.
      
      This patch should fix Trac#14885.
      Signed-off-by: Tao He's avatarHE, Tao <sighingnow@gmail.com>
      
      Test Plan: make test TEST="T14885a T14885b T14885c"
      
      Reviewers: goldfire, bgamari, simonpj, RyanGlScott
      
      Reviewed By: simonpj, RyanGlScott
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14885
      
      Differential Revision: https://phabricator.haskell.org/D4469
      a3986d7f
    • Alec Theriault's avatar
      Support adding objects from TH · ceb91477
      Alec Theriault authored
      The user facing TH interface changes are:
      
        * 'addForeignFile' is renamed to 'addForeignSource'
        * 'qAddForeignFile'/'addForeignFile' now expect 'FilePath's
        * 'RawObject' is now a constructor for 'ForeignSrcLang'
        * 'qAddTempFile'/'addTempFile' let you request a temporary file
          from the compiler.
      
      Test Plan: unsure about this, added a TH test
      
      Reviewers: goldfire, bgamari, angerman
      
      Reviewed By: bgamari, angerman
      
      Subscribers: hsyl20, mboes, carter, simonmar, bitonic, ljli, rwbarton, thomie
      
      GHC Trac Issues: #14298
      
      Differential Revision: https://phabricator.haskell.org/D4217
      ceb91477
  15. 21 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14869 by being more mindful of Type vs. Constraint · 49ac3f0f
      Ryan Scott authored
      Summary:
      Before, we were using `isLiftedTypeKind` in `reifyType`
      before checking if a type was `Constraint`. But as it turns out,
      `isLiftedTypeKind` treats `Constraint` the same as `Type`, so every
      occurrence of `Constraint` would be reified as `Type`! To make things
      worse, the documentation for `isLiftedTypeKind` stated that it
      treats `Constraint` //differently// from `Type`, which simply isn't
      true.
      
      This revises the documentation for `isLiftedTypeKind` to reflect
      reality, and defers the `isLiftedTypeKind` check in `reifyType` so
      that it does not accidentally swallow `Constraint`.
      
      Test Plan: make test TEST=T14869
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14869
      
      Differential Revision: https://phabricator.haskell.org/D4474
      49ac3f0f
  16. 19 Mar, 2018 1 commit
    • Chaitanya Koparkar's avatar
      Turn a TH Name for built-in syntax into an unqualified RdrName · 9868f91f
      Chaitanya Koparkar authored
      Previously, the Renamer would turn any fully qualified Template Haskell
      name into a corresponding fully qualified `RdrName`. But this is not
      what we want for built-in syntax, as it produces unnecessarily qualified
      names (eg. GHC.Types.[], GHC.Tuple.(,) etc.).
      
      Test Plan: ./validate
      
      Reviewers: RyanGlScott, bgamari, goldfire
      
      Reviewed By: RyanGlScott, bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #13776
      
      Differential Revision: https://phabricator.haskell.org/D4506
      9868f91f
  17. 05 Mar, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14888 by adding more special cases for ArrowT · 6ee831f2
      Ryan Scott authored
      Summary:
      There were previously some situations where `(->)` would
      not be desugared or reified as `ArrowT`, leading to various oddities
      such as those observed in #14888. We now uniformly treat `(->)` as
      `ArrowT` in Template Haskell–world by checking for any tycon that
      has the same name as `(->)`, and converting that to `ArrowT`.
      
      Test Plan: make test TEST=T14888
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: goldfire, simonpj
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14888
      
      Differential Revision: https://phabricator.haskell.org/D4466
      6ee831f2
  18. 02 Mar, 2018 3 commits
    • Ryan Scott's avatar
      Fix #14838 by marking TH-spliced code as FromSource · ffb2738f
      Ryan Scott authored
      Previously, any Template Haskell code that was spliced would
      be marked as `Generated`, which would completely suppress pattern-
      match coverage warnings for it, which several folks found confusing.
      Indeed, Template Haskell-spliced code is "source" code in some sense,
      as users specifically request that it be put into their program, so
      changing its designation to `FromSource` makes sense from that
      perspective.
      
      Test Plan: make test TEST=T14838
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14838
      
      Differential Revision: https://phabricator.haskell.org/D4440
      ffb2738f
    • Ryan Scott's avatar
      Permit conversion of partially applied PromotedTupleTs · 68357020
      Ryan Scott authored
      Summary:
      We were simply missing a case in `Convert` for when have a
      `PromotedTupleT` that wasn't fully saturated. Easily fixed.
      
      Test Plan: make test TEST=T14843
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14843
      
      Differential Revision: https://phabricator.haskell.org/D4442
      68357020
    • Ryan Scott's avatar
      Fix #14817 by not double-printing data family instance kind signatures · aef2b429
      Ryan Scott authored
      Within `pprDataFamInstDecl`, we were invoking `pprFamInstLHS` to
      pretty-print a data family instance header, and we were passing `Just` a
      kind signature to `pprFamInstLHS` to make it pretty-print the kind
      signature alongside it (this is a consequence of commit
      d1ef223c). But this is silly, because
      then invoke `pp_data_defn`, which //also// pretty-prints the kind
      signature, resulting in the kind signature being printed twice by
      mistake.
      
      This fix is simple—pass `Nothing` to `pprFamInstLHS` instead.
      
      Test Plan: make test TEST=T14817
      
      Reviewers: alanz, bgamari, mpickering
      
      Reviewed By: mpickering
      
      Subscribers: mpickering, rwbarton, thomie, carter
      
      GHC Trac Issues: #14817
      
      Differential Revision: https://phabricator.haskell.org/D4418
      aef2b429
  19. 18 Jan, 2018 2 commits
    • Ryan Scott's avatar
      Fix #14681 and #14682 with precision-aimed parentheses · 575c009d
      Ryan Scott authored
      It turns out that `Convert` was recklessly leaving off
      parentheses in two places:
      
      * Negative numeric literals
      * Patterns in lambda position
      
      This patch fixes it by adding three new functions, `isCompoundHsLit`,
      `isCompoundHsOverLit`, and `isCompoundPat`, and using them in the
      right places in `Convert`. While I was in town, I also sprinkled
      `isCompoundPat` among some `Pat`-constructing functions in `HsUtils`
      to help avoid the likelihood of this problem happening in other
      places. One of these places is in `TcGenDeriv`, and sprinkling
      `isCompountPat` there fixes #14682
      
      Test Plan: make test TEST="T14681 T14682"
      
      Reviewers: alanz, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #14681, #14682
      
      Differential Revision: https://phabricator.haskell.org/D4323
      575c009d
    • Matthías Páll Gissurarson's avatar
      Inform hole substitutions of typeclass constraints (fixes #14273). · 1e14fd3e
      Matthías Páll Gissurarson authored
      This implements SPJ's suggestion on the ticket (#14273). We find the
      relevant constraints (ones that whose free unification variables are all
      mentioned in the type of the hole), and then clone the free unification
      variables of the hole and the relevant constraints. We then add a
      subsumption constraints and run the simplifier, and then check whether
      all the constraints were solved.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: RyanGlScott, rwbarton, thomie, carter
      
      GHC Trac Issues: #14273
      
      Differential Revision: https://phabricator.haskell.org/D4315
      1e14fd3e
  20. 15 Jan, 2018 1 commit
  21. 07 Oct, 2017 1 commit
    • Ryan Scott's avatar
      Incorporate changes from #11721 into Template Haskell · 341d3a78
      Ryan Scott authored
      Summary:
      #11721 changed the order of type variables in GADT
      constructor type signatures, but these changes weren't reflected in
      Template Haskell reification of GADTs. Let's do that.
      
      Along the way, I:
      
      * noticed that the `T13885` test was claiming to test TH reification
        of GADTs, but the reified data type wasn't actually a GADT! Since
        this patch touches that part of the codebase, I decided to fix
        this.
      * incorporated some feedback from @simonpj in
        https://phabricator.haskell.org/D3687#113566. (These changes alone
        don't account for any different in behavior.)
      
      Test Plan: make test TEST=T11721_TH
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: goldfire, bgamari, simonpj
      
      Subscribers: rwbarton, thomie, simonpj
      
      GHC Trac Issues: #11721
      
      Differential Revision: https://phabricator.haskell.org/D4070
      341d3a78
  22. 13 Sep, 2017 1 commit
    • Ryan Scott's avatar
      Check if -XStaticPointers is enabled when renaming static expressions · 9ff9c358
      Ryan Scott authored
      Summary:
      Trying to use `static` expressions without the `-XStaticPointers`
      extension enabled can lead to runtime errors. Normally, such a situation isn't
      possible, but Template Haskell provides a backdoor that allows it to happen,
      as shown in #14204.
      
      To prevent this, we ensure that `-XStaticPointers` is enabled when renaming
      `static` expressions.
      
      Test Plan: make test TEST=T14204
      
      Reviewers: facundominguez, austin, bgamari, simonpj
      
      Reviewed By: facundominguez, simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #14204
      
      Differential Revision: https://phabricator.haskell.org/D3931
      9ff9c358
  23. 22 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13885 by freshening reified GADT constructors' universal tyvars · 79b259ae
      Ryan Scott authored
      Summary:
      When reifying GADTs with Template Haskell, the universally quantified
      type variables were being reused across both the data type head and the
      constructors' type signatures. This had the annoying effect of causing sets
      of differently scoped variables to have the same uniques. To avoid this, we
      now freshen the universal tyvars before reifying the constructors so as to
      ensure they have distinct uniques.
      
      Test Plan: make test TEST=T13885
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #13885
      
      Differential Revision: https://phabricator.haskell.org/D3867
      79b259ae
  24. 15 Aug, 2017 1 commit
    • Ryan Scott's avatar
      Fix #14060 by more conservatively annotating TH-reified types · ad7b9452
      Ryan Scott authored
      Before, TH was quite generous in applying kind annotations to reified
      type constructors whose result kind happened to mention type variables.
      This could result in agonizingly large reified types, so this patch aims
      to quell this a bit by adopting a more nuanced algorithm for determining
      when a tycon application deserves a kind annotation.
      
      This implements the algorithm laid out in
      https://ghc.haskell.org/trac/ghc/ticket/14060#comment:1. I've updated
      `Note [Kind annotations on TyConApps]` to reflect the new wisdom.
      Essentially, instead of only checking if the result kind contains free
      variables, we also check if any of those variables do not appear free in
      injective positions in the argument kinds—only then do we put on a kind
      annotation.
      
      Bumps `haddock` submodule.
      
      Test Plan: make test TEST=T14060
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #14060
      
      Differential Revision: https://phabricator.haskell.org/D3807
      ad7b9452
  25. 29 Jul, 2017 1 commit
  26. 28 Jul, 2017 2 commits
    • Ryan Scott's avatar
      Merge types and kinds in DsMeta · b3b564fb
      Ryan Scott authored
      Summary:
      Types and kinds are now the same in GHC... well, except in the code
      that involves Template Haskell, where types and kinds are given separate
      treatment. This aims to unify that treatment in the `DsMeta` module.
      
      The gist of this patch is replacing all uses of `repLKind` with `repLTy`.
      This is isn't quite as simple as one might imagine, since `repLTy` returns a
      `Core (Q Type)` (a monadic expression), whereas `repLKind` returns a
      `Core Kind` (a pure expression). This causes many awkward impedance mismatches.
      
      One option would be to change every combinator in `Language.Haskell.TH.Lib` to
      take `KindQ` as an argument instead of `Kind`. But this would be a breaking
      change of colossal proportions.
      
      Instead, this patch takes a somewhat different approach. This migrates the
      existing `Language.Haskell.TH.Lib` module to
      `Language.Haskell.TH.Lib.Internal`, and changes all `Kind`-related combinators
      in `Language.Haskell.TH.Lib.Internal` to live in `Q`. The new
      `Language.Haskell.TH.Lib` module then re-exports most of
      `Language.Haskell.TH.Lib.Internal` with the exception of the `Kind`-related
      combinators, for which it redefines them to be their current definitions (which
      don't live in `Q`). This allows us to retain backwards compatibility with
      previous `template-haskell` releases, but more importantly, it allows GHC to
      make as many changes to the `Internal` code as it wants for its purposes
      without fear of disrupting the public API.
      
      This solves half of #11785 (the other half being `TcSplice`).
      
      Test Plan: ./validate
      
      Reviewers: goldfire, austin, bgamari
      
      Reviewed By: goldfire
      
      Subscribers: rwbarton, thomie
      
      GHC Trac Issues: #11785
      
      Differential Revision: https://phabricator.haskell.org/D3751
      b3b564fb
    • Ryan Scott's avatar
      Error eagerly after renaming failures in reifyInstances · d6186496
      Ryan Scott authored
      Summary:
      Previously, if `reifyInstances` failed to discover a `Name` during
      renaming, it would blindy charge into typechecking, at which point GHC would
      become very confused at the absence of that `Name` and throw an internal error.
      A simple workaround is to fail eagerly after renaming errors.
      
      Test Plan: make test TEST=T13837
      
      Reviewers: goldfire, austin, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: simonpj, rwbarton, thomie
      
      GHC Trac Issues: #13837
      
      Differential Revision: https://phabricator.haskell.org/D3793
      d6186496
  27. 26 Jul, 2017 1 commit
    • Ryan Scott's avatar
      Fix #13968 by consulting isBuiltInOcc_maybe · d774b4e2
      Ryan Scott authored
      Summary:
      We were unconditionally reporting `Illegal binding of built-in syntax`
      in an error message, but this error doesn't make sense in certain Template
      Haskell scenarios which can trigger it. Let's give a more sensible error
      message by first checking if the name we're binding really is built-in syntax,
      using the handy `isBuiltInOcc_maybe` function.
      
      Test Plan: make test TEST=T13968
      
      Reviewers: bgamari, austin, goldfire
      
      Reviewed By: goldfire
      
      Subscribers: goldfire, rwbarton, thomie
      
      GHC Trac Issues: #13968
      
      Differential Revision: https://phabricator.haskell.org/D3789
      d774b4e2
  28. 11 Jul, 2017 1 commit
  29. 23 Jun, 2017 1 commit
  30. 21 Jun, 2017 1 commit
  31. 12 Jun, 2017 1 commit
  32. 11 May, 2017 1 commit
  33. 04 May, 2017 1 commit
    • Simon Peyton Jones's avatar
      Deal with exceptions in dsWhenNoErrs · e7701976
      Simon Peyton Jones authored
      Gracious me.  Ever since this patch
      
        commit 37445780
        Author: Jan Stolarek <jan.stolarek@p.lodz.pl>
        Date:   Fri Jul 11 13:54:45 2014 +0200
      
            Injective type families
      
      TcRnMonad.askNoErrs has been wrong. It looked like this
      
         askNoErrs :: TcRn a -> TcRn (a, Bool)
         askNoErrs m
          = do { errs_var <- newTcRef emptyMessages
               ; res  <- setErrsVar errs_var m
               ; (warns, errs) <- readTcRef errs_var
               ; addMessages (warns, errs)
               ; return (res, isEmptyBag errs) }
      
      The trouble comes if 'm' throws an exception in the TcRn monad.
      Then 'errs_var is never read, so any errors are simply lost.
      
      This mistake was then propgated into DsMonad.dsWhenNoErrs, where
      it gave rise to Trac #13642.
      
      Thank to Ryan for narrowing it down so sharply.
      
      I did some refactoring, as usual.
      e7701976