1. 28 Nov, 2019 1 commit
  2. 27 Nov, 2019 1 commit
    • Sebastian Graf's avatar
      Make warnings for TH splices opt-in · 5a08f7d4
      Sebastian Graf authored
      In #17270 we have the pattern-match checker emit incorrect warnings. The
      reason for that behavior is ultimately an inconsistency in whether we
      treat TH splices as written by the user (`FromSource :: Origin`) or as
      generated code (`Generated`). This was first reported in #14838.
      
      The current solution is to TH splices as `Generated` by default and only
      treat them as `FromSource` when the user requests so
      (-fenable-th-splice-warnings). There are multiple reasons for opt-in
      rather than opt-out:
      
        * It's not clear that the user that compiles a splice is the author of the code
          that produces the warning. Think of the situation where she just splices in
          code from a third-party library that produces incomplete pattern matches.
          In this scenario, the user isn't even able to fix that warning.
        * Gathering information for producing the warnings (pattern-match check
          warnings in particular) is costly. There's no point in doing so if the user
          is not interested in those warnings.
      
      Fixes #17270, but not #14838, because the proper solution needs a GHC
      proposal extending the TH AST syntax.
      5a08f7d4
  3. 24 Nov, 2019 1 commit
  4. 20 Nov, 2019 1 commit
  5. 19 Nov, 2019 2 commits
    • Ben Gamari's avatar
      Give seq a more precise type and remove magic · 08d595c0
      Ben Gamari authored
      `GHC.Prim.seq` previously had the rather plain type:
      
          seq :: forall a b. a -> b -> b
      
      However, it also had a special typing rule to applications
      where `b` is not of kind `Type`.
      
      Issue #17440 noted that levity polymorphism allows us to rather give
      it the more precise type:
      
          seq :: forall (r :: RuntimeRep) a (b :: TYPE r). a -> b -> b
      
      This allows us to remove the special typing rule that we previously
      required to allow applications on unlifted arguments. T9404 contains a
      non-Type application of `seq` which should verify that this works as
      expected.
      
      Closes #17440.
      08d595c0
    • Alex D's avatar
      Optimize MonadUnique instances based on IO (#16843) · 88013b78
      Alex D authored
      Metric Decrease:
          T14683
      88013b78
  6. 17 Nov, 2019 1 commit
  7. 13 Nov, 2019 1 commit
    • Ben Gamari's avatar
      Ensure that coreView/tcView are able to inline · 2d4f9ad8
      Ben Gamari authored
      Previously an import cycle between Type and TyCoRep meant that several
      functions in TyCoRep ended up SOURCE import coreView. This is quite
      unfortunate as coreView is intended to be fused into a larger pattern
      match and not incur an extra call.
      
      Fix this with a bit of restructuring:
      
       * Move the functions in `TyCoRep` which depend upon things in `Type`
         into `Type`
       * Fold contents of `Kind` into `Type` and turn `Kind` into a simple
         wrapper re-exporting kind-ish things from `Type`
       * Clean up the redundant imports that popped up as a result
      
      Closes #17441.
      
      Metric Decrease:
          T4334
      2d4f9ad8
  8. 10 Nov, 2019 2 commits
  9. 05 Nov, 2019 1 commit
    • Sebastian Graf's avatar
      Check EmptyCase by simply adding a non-void constraint · 1593debf
      Sebastian Graf authored
      We can handle non-void constraints since !1733, so we can now express
      the strictness of `-XEmptyCase` just by adding a non-void constraint
      to the initial Uncovered set.
      
      For `case x of {}` we thus check that the Uncovered set `{ x | x /~ ⊥ }`
      is non-empty. This is conceptually simpler than the plan outlined in
       #17376, because it talks to the oracle directly.
      
      In order for this patch to pass the testsuite, I had to fix handling of
      newtypes in the pattern-match checker (#17248).
      
      Since we use a different code path (well, the main code path) for
      `-XEmptyCase` now, we apparently also handle #13717 correctly.
      There's also some dead code that we can get rid off now.
      
      `provideEvidence` has been updated to provide output more in line with
      the old logic, which used `inhabitationCandidates` under the hood.
      
      A consequence of the shift away from the `UncoveredPatterns` type is
      that we don't report reduced type families for empty case matches,
      because the pretty printer is pure and only knows the match variable's
      type.
      
      Fixes #13717, #17248, #17386
      1593debf
  10. 03 Nov, 2019 1 commit
    • Sebastian Graf's avatar
      Separate `LPat` from `Pat` on the type-level · 182b1199
      Sebastian Graf authored
      Since the Trees That Grow effort started, we had `type LPat = Pat`.
      This is so that `SrcLoc`s would only be annotated in GHC's AST, which is
      the reason why all GHC passes use the extension constructor `XPat` to
      attach source locations. See #15495 for the design discussion behind
      that.
      
      But now suddenly there are `XPat`s everywhere!
      There are several functions which dont't cope with `XPat`s by either
      crashing (`hsPatType`) or simply returning incorrect results
      (`collectEvVarsPat`).
      
      This issue was raised in #17330. I also came up with a rather clean and
      type-safe solution to the problem: We define
      
      ```haskell
      type family XRec p (f :: * -> *) = r | r -> p f
      type instance XRec (GhcPass p) f = Located (f (GhcPass p))
      type instance XRec TH          f =          f p
      type LPat p = XRec p Pat
      ```
      
      This is a rather modular embedding of the old "ping-pong" style, while
      we only pay for the `Located` wrapper within GHC. No ping-ponging in
      a potential Template Haskell AST, for example. Yet, we miss no case
      where we should've handled a `SrcLoc`: `hsPatType` and
      `collectEvVarsPat` are not callable at an `LPat`.
      
      Also, this gets rid of one indirection in `Located` variants:
      Previously, we'd have to go through `XPat` and `Located` to get from
      `LPat` to the wrapped `Pat`. Now it's just `Located` again.
      
      Thus we fix #17330.
      182b1199
  11. 30 Oct, 2019 1 commit
    • Vladislav Zavialov's avatar
      Whitespace forward compatibility for proposal #229 · 3e7569bc
      Vladislav Zavialov authored
      GHC Proposal #229 changes the lexical rules of Haskell, which may
      require slight whitespace adjustments in certain cases.
      
      This patch changes formatting in a few places in GHC and its testsuite
      in a way that enables it to compile under the proposed rules.
      3e7569bc
  12. 29 Oct, 2019 1 commit
  13. 28 Oct, 2019 3 commits
    • Sebastian Graf's avatar
      Use FlexibleInstances for `Outputable (* p)` instead of match-all instances... · e951f219
      Sebastian Graf authored
      Use FlexibleInstances for `Outputable (* p)` instead of match-all instances with equality constraints
      
      In #17304, Richard and Simon dicovered that using `-XFlexibleInstances`
      for `Outputable` instances of AST data types means users can provide orphan
      `Outputable` instances for passes other than `GhcPass`.
      
      Type inference doesn't currently to suffer, and Richard gave an example
      in #17304 that shows how rare a case would be where the slightly worse
      type inference would matter.
      
      So I went ahead with the refactoring, attempting to fix #17304.
      e951f219
    • Ryan Scott's avatar
      Refactor TcDeriv to validity-check less in anyclass/via deriving (#13154) · cd9b9459
      Ryan Scott authored
      Due to the way `DerivEnv` is currently structured, there is an
      invariant that every derived instance must consist of a class applied
      to a non-empty list of argument types, where the last argument *must*
      be an application of a type constructor to some arguments. This works
      for many cases, but there are also some design patterns in standalone
      `anyclass`/`via` deriving that are made impossible due to enforcing
      this invariant, as documented in #13154.
      
      This fixes #13154 by refactoring `TcDeriv` and friends to perform
      fewer validity checks when using the `anyclass` or `via` strategies.
      The highlights are as followed:
      
      * Five fields of `DerivEnv` have been factored out into a new
        `DerivInstTys` data type. These fields only make sense for
        instances that satisfy the invariant mentioned above, so
        `DerivInstTys` is now only used in `stock` and `newtype` deriving,
        but not in other deriving strategies.
      * There is now a `Note [DerivEnv and DerivSpecMechanism]` describing
        the bullet point above in more detail, as well as explaining the
        exact requirements that each deriving strategy imposes.
      * I've refactored `mkEqnHelp`'s call graph to be slightly less
        complicated. Instead of the previous `mkDataTypeEqn`/`mkNewTypeEqn`
        dichotomy, there is now a single entrypoint `mk_eqn`.
      * Various bits of code were tweaked so as not to use fields that are
        specific to `DerivInstTys` so that they may be used by all deriving
        strategies, since not all deriving strategies use `DerivInstTys`.
      cd9b9459
    • Josef Svenningsson's avatar
      Fix #15344: use fail when desugaring applicative-do · 6635a3f6
      Josef Svenningsson authored
      Applicative-do has a bug where it fails to use the monadic fail method
      when desugaring patternmatches which can fail. See #15344.
      
      This patch fixes that problem. It required more rewiring than I had expected.
      Applicative-do happens mostly in the renamer; that's where decisions about
      scheduling are made. This schedule is then carried through the typechecker and
      into the desugarer which performs the actual translation. Fixing this bug
      required sending information about the fail method from the renamer, through
      the type checker and into the desugarer. Previously, the desugarer didn't
      have enough information to actually desugar pattern matches correctly.
      
      As a side effect, we also fix #16628, where GHC wouldn't catch missing
      MonadFail instances with -XApplicativeDo.
      6635a3f6
  14. 23 Oct, 2019 3 commits
    • Andreas Klebinger's avatar
      Make dynflag argument for withTiming pure. · 6beea836
      Andreas Klebinger authored
      19 times out of 20 we already have dynflags in scope.
      
      We could just always use `return dflags`. But this is in fact not free.
      When looking at some STG code I noticed that we always allocate a
      closure for this expression in the heap. Clearly a waste in these cases.
      
      For the other cases we can either just modify the callsite to
      get dynflags or use the _D variants of withTiming I added which
      will use getDynFlags under the hood.
      6beea836
    • Ryan Scott's avatar
      Reify oversaturated data family instances correctly (#17296) · a19c7d17
      Ryan Scott authored
      `TcSplice` was not properly handling oversaturated data family
      instances, such as the example in #17296, as it dropped arguments due
      to carelessly zipping data family instance arguments with
      `tyConTyVars`. For data families, the number of `tyConTyVars` can
      sometimes be less than the number of arguments it can accept in a
      data family instance due to the fact that data family instances can
      be oversaturated.
      
      To account for this, `TcSplice.mkIsPolyTvs` has now been renamed to
      `tyConArgsPolyKinded` and now factors in `tyConResKind` in addition
      to `tyConTyVars`. I've also added
      `Note [Reified instances and explicit kind signatures]` which
      explains the various subtleties in play here.
      
      Fixes #17296.
      a19c7d17
    • Richard Eisenberg's avatar
      Implement a coverage checker for injectivity · 1cd3fa29
      Richard Eisenberg authored
      This fixes #16512.
      
      There are lots of parts of this patch:
      
      * The main payload is in FamInst. See
      Note [Coverage condition for injective type families] there
      for the overview. But it doesn't fix the bug.
      
      * We now bump the reduction depth every time we discharge
      a CFunEqCan. See Note [Flatten when discharging CFunEqCan]
      in TcInteract.
      
      * Exploration of this revealed a new, easy to maintain invariant
      for CTyEqCans. See Note [Almost function-free] in TcRnTypes.
      
      * We also realized that type inference for injectivity was a
      bit incomplete. This means we exchanged lookupFlattenTyVar for
      rewriteTyVar. See Note [rewriteTyVar] in TcFlatten. The new
      function is monadic while the previous one was pure, necessitating
      some faff in TcInteract. Nothing too bad.
      
      * zonkCt did not maintain invariants on CTyEqCan. It's not worth
      the bother doing so, so we just transmute CTyEqCans to
      CNonCanonicals.
      
      * The pure unifier was finding the fixpoint of the returned
      substitution, even when doing one-way matching (in tcUnifyTysWithTFs).
      Fixed now.
      
      Test cases: typecheck/should_fail/T16512{a,b}
      1cd3fa29
  15. 17 Oct, 2019 1 commit
  16. 16 Oct, 2019 2 commits
    • Richard Eisenberg's avatar
      Break up TcRnTypes, among other modules. · 51fad9e6
      Richard Eisenberg authored
      This introduces three new modules:
      
       - basicTypes/Predicate.hs describes predicates, moving
         this logic out of Type. Predicates don't really exist
         in Core, and so don't belong in Type.
      
       - typecheck/TcOrigin.hs describes the origin of constraints
         and types. It was easy to remove from other modules and
         can often be imported instead of other, scarier modules.
      
       - typecheck/Constraint.hs describes constraints as used in
         the solver. It is taken from TcRnTypes.
      
      No work other than module splitting is in this patch.
      
      This is the first step toward homogeneous equality, which will
      rely more strongly on predicates. And homogeneous equality is the
      next step toward a dependently typed core language.
      51fad9e6
    • Sebastian Graf's avatar
      Infer rho-types instead of sigma-types in guard BindStmts and TransStmts · 6ede3554
      Sebastian Graf authored
      In #17343 we saw that we didn't handle the pattern guard `!_ <-
      undefined` correctly: The `undefined` was never evaluated. Indeed,
      elaboration failed to insert the invisible type aruments to `undefined`.
      So `undefined` was trivially a normal-form and in turn never entered.
      
      The problem is that we used to infer a sigma-type for the RHS of the
      guard, the leading qualifiers of which will never be useful in a pattern
      match situation. Hence we infer a rho-type now.
      
      Fixes #17343.
      6ede3554
  17. 15 Oct, 2019 2 commits
    • Ryan Scott's avatar
      Don't skip validity checks for built-in classes (#17355) · 426b0ddc
      Ryan Scott authored
      Issue #17355 occurred because the control flow for
      `TcValidity.check_valid_inst_head` was structured in such a way that
      whenever it checked a special, built-in class (like `Generic` or
      `HasField`), it would skip the most important check of all:
      `checkValidTypePats`, which rejects nonsense like this:
      
      ```hs
      instance Generic (forall a. a)
      ```
      
      This fixes the issue by carving out `checkValidTypePats` from
      `check_valid_inst_head` so that `checkValidTypePats` is always
      invoked. `check_valid_inst_head` has also been renamed to
      `check_special_inst_head` to reflect its new purpose of _only_
      checking for instances headed by special classes.
      
      Fixes #17355.
      426b0ddc
    • Ryan Scott's avatar
      Refactor some cruft in TcDerivInfer.inferConstraints · a2d3594c
      Ryan Scott authored
      The latest installment in my quest to clean up the code in
      `TcDeriv*`. This time, my sights are set on
      `TcDerivInfer.inferConstraints`, which infers the context for derived
      instances. This function is a wee bit awkward at the moment:
      
      * It's not terribly obvious from a quick glance, but
        `inferConstraints` is only ever invoked when using the `stock` or
        `anyclass` deriving strategies, as the code for inferring the
        context for `newtype`- or `via`-derived instances is located
        separately in `mk_coerce_based_eqn`. But there's no good reason
        for things to be this way, so I moved this code from
        `mk_coerce_based_eqn` to `inferConstraints` so that everything
        related to inferring instance contexts is located in one place.
      * In this process, I discovered that the Haddocks for the auxiliary
        function `inferConstraintsDataConArgs` are completely wrong. It
        claims that it handles both `stock` and `newtype` deriving, but
        this is completely wrong, as discussed above—it only handles
        `stock`. To rectify this, I renamed this function to
        `inferConstraintsStock` to reflect its actual purpose and created
        a new `inferConstraintsCoerceBased` function to specifically
        handle `newtype` (and `via`) deriving.
      
      Doing this revealed some opportunities for further simplification:
      
      * Removing the context-inference–related code from
        `mk_coerce_based_eqn` made me realize that the overall structure
        of the function is basically identical to `mk_originative_eqn`.
        In fact, I was easily able to combine the two functions into a
        single `mk_eqn_from_mechanism` function.
      
        As part of this merger, I now invoke
        `atf_coerce_based_error_checks` from `doDerivInstErrorChecks1`.
      * I discovered that GHC defined this function:
      
        ```hs
        typeToTypeKind = liftedTypeKind `mkVisFunTy` liftedTypeKind
        ```
      
        No fewer than four times in different modules. I consolidated all
        of these definitions in a single location in `TysWiredIn`.
      a2d3594c
  18. 12 Oct, 2019 4 commits
    • Simon Peyton Jones's avatar
      Do not add a 'solved dict' for quantified constraints · 226d86d2
      Simon Peyton Jones authored
      GHC has a wonderful-but-delicate mechanism for building recursive
      dictionaries by adding a goal to the "solved dictionaries" before
      solving the sub-goals.  See Note [Solved dictionaries] in TcSMonad
      
      Ticket #17267 showed that if you use this mechanism for local
      /quantified/ constraints you can get a loop -- or even unsafe
      coerce.   This patch fixes the bug.
      
      Specifically
      
      * Make TcSMonad.addSolvedDict be conditional on using a
        /top level/ instance, not a quantified one.
      
      * Moreover, we /also/ don't want to add a solved dict
        for equalities (a~b).
      
      * Add lots more comments to Note [Solved dictionaries]
        to explain the above cryptic stuff.
      
      * Extend InstanceWhat to identify those strange built-in
        equality instances.
      
      A couple of other things along the way
      
      * Delete the unused Type.isIPPred_maybe.
      
      * Stop making addSolvedDict conditional on not being an
        impolicit parameter.  This comes from way back. But
        it's irrelevant now because IP dicts are never solved
        via an instance.
      226d86d2
    • Simon Peyton Jones's avatar
      Fix validity checking for inferred types · c50e4c92
      Simon Peyton Jones authored
      GHC is suposed to uphold the principle that an /inferred/ type
      for a let-binding should obey the rules for that module.  E.g.
      we should only accept an inferred higher rank type if we have
      RankNTypes on.
      
      But we were failing to check this: TcValidity.checkValidType
      allowed arbitrary rank for inferred types.
      
      This patch fixes the bug.  It might in principle cause some breakage,
      but if so that's good: the user should add RankNTypes and/or a
      manual signature.  (And almost every package has explicit user
      signatures for all top-level things anyway.)  Let's see.
      
      Fixes #17213.
      
      Metric Decrease:
          T10370
      c50e4c92
    • Ryan Scott's avatar
      Use newDFunName for both manual and derived instances (#17339) · 0a338264
      Ryan Scott authored
      Issue #17339 was caused by using a slightly different version of
      `newDFunName` for derived instances that, confusingly enough, did not
      take all arguments to the class into account when generating the
      `DFun` name. I cannot think of any good reason for doing this, so
      this patch uses `newDFunName` uniformly for both derived instances
      and manually written instances alike.
      
      Fixes #17339.
      0a338264
    • Sebastian Graf's avatar
      Much simpler language for PmCheck · 30f5ac07
      Sebastian Graf authored
      Simon realised that the simple language composed of let bindings, bang
      patterns and flat constructor patterns is enough to capture the
      semantics of the source pattern language that are important for
      pattern-match checking. Well, given that the Oracle is smart enough to
      connect the dots in this less informationally dense form, which it is
      now.
      
      So we transform `translatePat` to return a list of `PmGrd`s relative to
      an incoming match variable. `pmCheck` then trivially translates each of
      the `PmGrd`s into constraints that the oracle understands.
      
      Since we pass in the match variable, we incidentally fix #15884
      (coverage checks for view patterns) through an interaction with !1746.
      30f5ac07
  19. 09 Oct, 2019 1 commit
    • Ryan Scott's avatar
      Use addUsedDataCons more judiciously in TcDeriv (#17324) · d584e3f0
      Ryan Scott authored
      If you derive an instance like this:
      
      ```hs
      deriving <...> instance Foo C
      ```
      
      And the data constructors for `C` aren't in scope, then
      `doDerivInstErrorChecks1` throws an error. Moreover, it will
      _only_ throw an error if `<...>` is either `stock` or `newtype`.
      This is because the code that the `anyclass` or `via` strategies
      would generate would not require the use of the data constructors
      for `C`.
      
      However, `doDerivInstErrorChecks1` has another purpose. If you
      write this:
      
      ```hs
      import M (C(MkC1, ..., MkCn))
      
      deriving <...> instance Foo C
      ```
      
      Then `doDerivInstErrorChecks1` will call `addUsedDataCons` on
      `MkC1` through `MkCn` to ensure that `-Wunused-imports` does not
      complain about them. However, `doDerivInstErrorChecks1` was doing
      this for _every_ deriving strategy, which mean that if `<...>` were
      `anyclass` or `via`, then the warning about `MkC1` through `MkCn`
      being unused would be suppressed!
      
      The fix is simple enough: only call `addUsedDataCons` when the
      strategy is `stock` or `newtype`, just like the other code paths
      in `doDerivInstErrorChecks1`.
      
      Fixes #17324.
      d584e3f0
  20. 08 Oct, 2019 2 commits
    • Richard Eisenberg's avatar
      Solve constraints from top-level groups sooner · 9612e91c
      Richard Eisenberg authored
      Previously, all constraints from all top-level groups (as
      separated by top-level splices) were lumped together and solved
      at the end. This could leak metavariables to TH, though, and
      that's bad. This patch solves each group's constraints before
      running the next group's splice.
      
      Naturally, we now report fewer errors in some cases.
      
      One nice benefit is that this also fixes #11680, but in a much
      simpler way than the original fix for that ticket. Admittedly,
      the error messages degrade just a bit from the fix from #11680
      (previously, we informed users about variables that will be
      brought into scope below a top-level splice, and now we just
      report an out-of-scope error), but the amount of complexity
      required throughout GHC to get that error was just not worth it.
      
      This patch thus reverts much of
      f93c9517.
      
      Fixes #16980
      
      Test cases: th/T16980{,a}
      9612e91c
    • Ryan Scott's avatar
      Mark newtype constructors as used in the Coercible solver (#10347) · bf02c264
      Ryan Scott authored
      Currently, newtype constructors are not marked as used when they are
      accessed under the hood by uses of `coerce`, as described in #10347.
      This fixes #10347 by co-opting the `tcg_keep` field of `TcGblEnv`
      to track uses of newtype constructors in the `Coercible` solver.
      See `Note [Tracking unused binding and imports]` in `TcRnTypes`.
      
      Since #10347 is fixed, I was able to simplify the code in `TcDeriv`
      slightly, as the hack described in
      `Note [Newtype deriving and unused constructors]`
      is no longer necessary.
      bf02c264
  21. 07 Oct, 2019 1 commit
    • Ryan Scott's avatar
      Refactor some cruft in TcGenGenerics · ab945819
      Ryan Scott authored
      * `foldBal` contains needless partiality that can easily be avoided.
      * `mkProd_E` and `mkProd_P` both contain unique supply arguments that
        are completely unused, which can be removed.
      ab945819
  22. 05 Oct, 2019 2 commits
  23. 03 Oct, 2019 3 commits
    • Richard Eisenberg's avatar
      Improve documentation around empty tuples/lists · 6655ec73
      Richard Eisenberg authored
      This patch also changes the way we handle empty lists, simplifying
      them somewhat. See Note [Empty lists]. Previously, we had to
      special-case empty lists in the type-checker. Now no more!
      
      Finally, this patch improves some documentation around the ir_inst
      field used in the type-checker.
      
      This breaks a test case, but I really think the problem is #17251,
      not really related to this patch.
      
      Test case: typecheck/should_compile/T13680
      6655ec73
    • Richard Eisenberg's avatar
      Note [Don't flatten tuples from HsSyn] in MkCore · 3b9d4907
      Richard Eisenberg authored
      Previously, we would sometimes flatten 1-tuples and sometimes
      not. This didn't cause damage because there is no way to
      generate HsSyn with 1-tuples. But, with the upcoming fix to #16881,
      there will be. Without this patch, obscure lint errors would
      have resulted.
      
      No test case, as there is not yet a way to tickle this.
      3b9d4907
    • Ryan Scott's avatar
      Merge TcTypeableValidity into TcTypeable, document treatment of casts · 60229e9e
      Ryan Scott authored
      This patch:
      
      * Implements a refactoring (suggested in
        !1199 (comment 207345))
        that moves all functions from `TcTypeableValidity` back to
        `TcTypeable`, as the former module doesn't really need to live on its
        own.
      * Adds `Note [Typeable instances for casted types]` to `TcTypeable`
        explaining why the `Typeable` solver currently does not support
        types containing casts.
      
      Resolves #16835.
      60229e9e
  24. 01 Oct, 2019 2 commits
    • Ryan Scott's avatar
      Refactor some cruft in TcDeriv · 9c002177
      Ryan Scott authored
      * `mk_eqn_stock`, `mk_eqn_anyclass`, and `mk_eqn_no_mechanism` all
        took a continuation of type
        `DerivSpecMechanism -> DerivM EarlyDerivSpec` to represent its
        primary control flow. However, in practice this continuation was
        always instantiated with the `mk_originative_eqn` function, so
        there's not much point in making this be a continuation in the
        first place.
      
        This patch removes these continuations in favor of invoking
        `mk_originative_eqn` directly, which is simpler.
      * There were several parts of `TcDeriv` that took different code
        paths if compiling an `.hs-boot` file. But this is silly, because
        ever since 101a8c77 we simply error
        eagerly whenever attempting to derive any instances in an
        `.hs-boot` file.
      
        This patch removes all of the unnecessary `.hs-boot` code paths,
        leaving only one (which errors out).
      * Remove various error continuation arguments from `mk_eqn_stock`
        and related functions.
      9c002177
    • Sebastian Graf's avatar