1. 26 Apr, 2018 1 commit
    • Simon Peyton Jones's avatar
      Do not unpack class dictionaries with INLINABLE · 3d38e828
      Simon Peyton Jones authored
      Matthew Pickering uncovered a bad performance hole in the way
      that single-method dictionaries work, described in Trac #14955.
      
      See Note [Do not unpack class dictionaries] in WwLib.
      
      I tried to fix this 6 years ago, but got it slightly wrong.  This patch
      fixes it, which makes a dramatic improvement in the test case.
      
      Nofib highlights: not much happening:
      
        Program           Size    Allocs   Runtime   Elapsed  TotalMem
      -----------------------------------------------------------------
            VSM          -0.3%     +2.7%     -7.4%     -7.4%      0.0%
      cacheprof          -0.0%     +0.1%     +0.3%     +0.7%      0.0%
        integer          -0.0%     +1.1%     +7.5%     +7.5%      0.0%
            tak          -0.1%     -0.2%     0.024     0.024      0.0%
      -----------------------------------------------------------------
            Min          -4.4%     -0.2%     -7.4%     -7.4%     -8.0%
            Max          +0.6%     +2.7%     +7.5%     +7.5%      0.0%
      Geom Mean          -0.1%     +0.0%     +0.1%     +0.1%     -0.2%
      
      I investigated VSM.  The patch unpacks class dictionaries a bit more
      than before (i.e. does so if there is no INLINABLE pragma). And that
      gives better code in VSM (less dictionary selection etc), but one closure
      gets one word bigger.
      
      I'll accept these changes in exchange for more robust performance.
      
      Some ghci.debugger output wobbled around (order of bindings
      being displayed). I have no idea why; but I accepted the changes.
      3d38e828
  2. 24 Apr, 2018 2 commits
  3. 23 Apr, 2018 1 commit
  4. 20 Apr, 2018 4 commits
    • Tobias Dammers's avatar
      Remove unnecessary check in simplCast · 2a5bdd9a
      Tobias Dammers authored
      The coercion optimizer will take care of it anyway, and the check is
      prohibitively expensive.
      
      See Trac #14737.
      
      Reviewers: bgamari
      
      Subscribers: simonpj, thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4568
      2a5bdd9a
    • Simon Peyton Jones's avatar
      Inline wrappers earlier · 8b10b896
      Simon Peyton Jones authored
      This patch has a single significant change:
      
        strictness wrapper functions are inlined earlier,
        in phase 2 rather than phase 0.
      
      As shown by Trac #15056, this gives a better chance for RULEs to fire.
      Before this change, a function that would have inlined early without
      strictness analyss was instead inlining late. Result: applying
      "optimisation" made the program worse.
      
      This does not make too much difference in nofib, but I've stumbled
      over the problem more than once, so even a "no-change" result would be
      quite acceptable.  Here are the headlines:
      
      --------------------------------------------------------------------------------
              Program           Size    Allocs   Runtime   Elapsed  TotalMem
      --------------------------------------------------------------------------------
            cacheprof          -0.5%     -0.5%     +2.5%     +2.5%      0.0%
               fulsom          -1.0%     +2.6%     -0.1%     -0.1%      0.0%
                 mate          -0.6%     +2.4%     -0.9%     -0.9%      0.0%
              veritas          -0.7%    -23.2%     0.002     0.002      0.0%
      --------------------------------------------------------------------------------
                  Min          -1.4%    -23.2%    -12.5%    -15.3%      0.0%
                  Max          +0.6%     +2.6%     +4.4%     +4.3%    +19.0%
       Geometric Mean          -0.7%     -0.2%     -1.4%     -1.7%     +0.2%
      
      * A worthwhile reduction in binary size.
      
      * Runtimes are not to be trusted much but look as if they
        are moving the right way.
      
      * A really big win in veritas, described in comment:1 of
        Trac #15056; more fusion rules fired.
      
      * I investigated the losses in 'mate' and 'fulsom'; see #15056.
      8b10b896
    • Tobias Dammers's avatar
      Caching coercion roles in NthCo and coercionKindsRole refactoring · 2fbe0b51
      Tobias Dammers authored
      While addressing nonlinear behavior related to coercion roles,
      particularly `NthCo`, we noticed that coercion roles are recalculated
      often even though they should be readily at hand already in most cases.
      This patch adds a `Role` to the `NthCo` constructor so that we can cache
      them rather than having to recalculate them on the fly.
      https://ghc.haskell.org/trac/ghc/ticket/11735#comment:23 explains the
      approach.
      
      Performance improvement over GHC HEAD, when compiling Grammar.hs (see below):
      
      GHC 8.2.1:
      ```
      ghc Grammar.hs  176.27s user 0.23s system 99% cpu 2:56.81 total
      ```
      
      before patch (but with other optimizations applied):
      ```
      ghc Grammar.hs -fforce-recomp  175.77s user 0.19s system 100% cpu 2:55.78 total
      ```
      
      after:
      ```
      ../../ghc/inplace/bin/ghc-stage2 Grammar.hs  10.32s user 0.17s system 98% cpu 10.678 total
      ```
      
      Introduces the following regressions:
      
      - perf/compiler/parsing001 (possibly false positive)
      - perf/compiler/T9872
      - perf/compiler/haddock.base
      
      Reviewers: goldfire, bgamari, simonpj
      
      Reviewed By: simonpj
      
      Subscribers: rwbarton, thomie, carter
      
      GHC Trac Issues: #11735
      
      Differential Revision: https://phabricator.haskell.org/D4394
      2fbe0b51
    • Ryan Scott's avatar
      Lint types in newFamInst · 257c13d8
      Ryan Scott authored
      We weren't linting the types used in `newFamInst`, which
      might have been why #15012 went undiscovered for so long. Let's fix
      that.
      
      One has to be surprisingly careful with expanding type synonyms in
      `lintType`, since in the offending program (simplified):
      
      ```lang=haskell
      type FakeOut a = Int
      
      type family TF a
      type instance TF Int = FakeOut a
      ```
      
      If one expands type synonyms, then `FakeOut a` will expand to
      `Int`, which masks the issue (that `a` is unbound). I added an
      extra Lint flag to configure whether type synonyms should be
      expanded or not in Lint, and disabled this when calling `lintTypes`
      from `newFamInst`.
      
      As evidence that this works, I ran it on the offending program
      from #15012, and voilà:
      
      ```
      $ ghc3/inplace/bin/ghc-stage2 Bug.hs -dcore-lint
      [1 of 1] Compiling Foo              ( Bug.hs, Bug.o )
      ghc-stage2: panic! (the 'impossible' happened)
        (GHC version 8.5.20180417 for x86_64-unknown-linux):
              Core Lint error
        <no location info>: warning:
            In the type ‘... (Rec0 (FakeOut b_a1Qt))))’
            @ b_a1Qt is out of scope
      ```
      
      Test Plan: make test TEST=T15057
      
      Reviewers: simonpj, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15057
      
      Differential Revision: https://phabricator.haskell.org/D4611
      257c13d8
  5. 19 Apr, 2018 7 commits
    • Alp Mestanogullari's avatar
      testsuite: Fix `./validate --slow` · d9d80151
      Alp Mestanogullari authored
      This fixes all unexpected passes and unexpected failures from a
      `./validate --slow` run I did last week. I commented on many
      tickets and created a few more as I was going through the failing
      tests. A summary of the entire process is available at:
      
        https://gist.github.com/alpmestan/c371840968f086c8dc5b56af8325f0a9
      
      This is part of an attempt to have `./validate --slow` pass,
      tracked in #14890. Another patch will be necessary for the unexpected
      stats failures.
      
      Test Plan: ./validate --slow (not green yet)
      
      Reviewers: bgamari, simonmar
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4546
      d9d80151
    • Ryan Scott's avatar
      Bump base to version 4.12.0.0 · 8f19ecc9
      Ryan Scott authored
      Summary: Bumps several submodules.
      
      Test Plan: ./validate
      
      Reviewers: hvr, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15018
      
      Differential Revision: https://phabricator.haskell.org/D4609
      8f19ecc9
    • Ryan Scott's avatar
      Fix #15012 with a well-placed use of Any · b08a6d75
      Ryan Scott authored
      Previously, derived `Generic1` instances could have associated `Rep1`
      type family instances with unbound variables, such as in the following
      example:
      
      ```lang=haskell
      data T a = MkT (FakeOut a) deriving Generic1
      type FakeOut a = Int
      
      ==>
      
      instance Generic1 T where
        type Rep1 T = ... (Rec0 (FakeOut a))
      ```
      
      Yikes! To avoid this, we simply map the last type variable in a
      derived `Generic1` instance to `Any`.
      
      Test Plan: make test TEST=T15012
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, thomie, carter
      
      GHC Trac Issues: #15012
      
      Differential Revision: https://phabricator.haskell.org/D4602
      b08a6d75
    • Tao He's avatar
      Better error message for empty character literal, for Trac #13450. · cac8be61
      Tao He authored
      For empty character literal, the `''`, report error message properly
      rather than just throw a "parser error" with wrong error location.
      
      Test Plan: make test TEST="T13450 T13450TH"
      
      Reviewers: goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, mpickering, carter
      
      GHC Trac Issues: #13450
      
      Differential Revision: https://phabricator.haskell.org/D4594
      cac8be61
    • Ömer Sinan Ağacan's avatar
      Add a test for #14815: · f7f567d5
      Ömer Sinan Ağacan authored
      Because the program doesn't have any binders that -XStrict can make
      strict, the desugarer output should be identical when it's compiled with
      and without -XStrict. This wasn't the case with GHC 8.2.2, but
      apparently it was fixed some time between 8.2.2 and 8.4.1. We now add a
      test case to make sure it stays fixed.
      
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: simonpj, rwbarton, thomie, carter
      
      GHC Trac Issues: #14815
      
      Differential Revision: https://phabricator.haskell.org/D4531
      f7f567d5
    • Ben Gamari's avatar
      Add a test case from the nested CPR work · 19ddd044
      Ben Gamari authored
      Reviewers: bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      Differential Revision: https://phabricator.haskell.org/D4565
      19ddd044
    • Ryan Scott's avatar
      Fix #14710 with more validity checks during renaming · 447d1264
      Ryan Scott authored
      Summary:
      #14710 revealed two unfortunate regressions related to kind
      polymorphism that had crept in in recent GHC releases:
      
      1. While GHC was able to catch illegal uses of kind polymorphism
         (i.e., if `PolyKinds` wasn't enabled) in limited situations, it
         wasn't able to catch kind polymorphism of the following form:
      
      ```lang=haskell
      f :: forall a. a -> a
      f x = const x g
        where
          g :: Proxy (x :: a)
          g = Proxy
      ```
      
      Note that the variable `a` is being used as a kind variable in the
      type signature of `g`, but GHC happily accepts it, even without
      the use of `PolyKinds`.
      
      2. If you have `PolyKinds` (but not `TypeInType`) enabled, then GHC
         incorrectly accepts the following definition:
      
      ```lang=haskell
      f :: forall k (a :: k). Proxy a
      f = Proxy
      ```
      
      Even though `k` is explicitly bound and then later used as a kind
      variable within the same telescope.
      
      This patch fixes these two bugs as follows:
      
      1. Whenever we rename any `HsTyVar`, we check if the following three
         criteria are met:
      
         (a) It's a type variable
         (b) It's used at the kind level
         (c) `PolyKinds` is not enabled
      
         If so, then we have found an illegal use of kind polymorphism, so
         throw an error.
      
         This check replaces the `checkBadKindBndrs` function, which could
         only catch illegal uses of kind polymorphism in very limited
         situations (when the bad kind variable happened to be implicitly
         quantified in the same type signature).
      
      2. In `extract_hs_tv_bndrs`, we must error if `TypeInType` is not
         enabled and either of the following criteria are met:
      
         (a) An explicitly bound type variable is used in kind position
             in the body of a `forall` type.
         (b) An explicitly bound type variable is used in kind position
             in the kind of a bound type variable in a `forall` type.
      
         `extract_hs_tv_bndrs` was checking (a), but not (b). Easily fixed.
      
      Test Plan: ./validate
      
      Reviewers: goldfire, simonpj, bgamari, hvr
      
      Reviewed By: simonpj
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #14710
      
      Differential Revision: https://phabricator.haskell.org/D4554
      447d1264
  6. 16 Apr, 2018 1 commit
  7. 13 Apr, 2018 5 commits
    • Sylvain Henry's avatar
      Enhanced constant folding · fea04def
      Sylvain Henry authored
      Until now GHC only supported basic constant folding (lit op lit, expr op
      0, etc.).
      
      This patch uses laws of +/-/* (associativity, commutativity,
      distributivity) to support some constant folding into nested
      expressions.
      
      Examples of new transformations:
      
         - simple nesting: (10 + x) + 10 becomes 20 + x
         - deep nesting: 5 + x + (y + (z + (t + 5))) becomes 10 + (x + (y + (z + t)))
         - distribution: (5 + x) * 6 becomes 30 + 6*x
         - simple factorization: 5 + x + (x + (x + (x + 5))) becomes 10 + (4 *x)
         - siblings: (5 + 4*x) - (3*x + 2) becomes 3 + x
      
      Test Plan: validate
      
      Reviewers: simonpj, austin, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie
      
      GHC Trac Issues: #9136
      
      Differential Revision: https://phabricator.haskell.org/D2858
      fea04def
    • Andreas Klebinger's avatar
      Omit ways depending on rts flags for #12870 related tests. · 9e89092d
      Andreas Klebinger authored
      Some of these tests instruct the RTS to ignore all RTS flags being
      passed.  While this is intended it causes test failures for some ways
      like profiling which depend on passing RTS flags. So we skip these ways.
      
      Test Plan: testsuite/tests/rts/flags$ make slow
      
      Reviewers: bgamari, simonmar, alpmestan
      
      Reviewed By: alpmestan
      
      Subscribers: alpmestan, thomie, carter
      
      GHC Trac Issues: #12870
      
      Differential Revision: https://phabricator.haskell.org/D4585
      9e89092d
    • Ryan Scott's avatar
      Fix #9438 by converting a panic to an error message · 7613a812
      Ryan Scott authored
      Previously, GHC was quite eager to panic whenever it was fed
      an archive file when `DYNAMIC_GHC_PROGRAMS=YES`. This ought to be an
      explicit error message instead, so this patch accomplishes just that.
      
      Test Plan: make test TEST=T14708
      
      Reviewers: Phyx, hvr, bgamari
      
      Reviewed By: Phyx
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #9438, #14708, #15032
      
      Differential Revision: https://phabricator.haskell.org/D4589
      7613a812
    • Ryan Scott's avatar
      Bump version numbers: base-4.11.1.0, integer-gmp-1.0.2.0 · c4814ab6
      Ryan Scott authored
      This takes care of bumping the `base` and `integer-gmp`
      minor version numbers in anticipation of a GHC 8.4.2 release.
      
      While I was in town, I also filled in a `@since TODO` Haddock
      annotation for `powModSecInteger` in `integer-gmp` with
      `1.0.2.0`, and updated the changelog accordingly.
      
      Test Plan: ./validate
      
      Reviewers: hvr, goldfire, bgamari
      
      Reviewed By: bgamari
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #15025
      
      Differential Revision: https://phabricator.haskell.org/D4586
      c4814ab6
    • Alan Zimmerman's avatar
      TTG for HsBinds and Data instances Plan B · b1386942
      Alan Zimmerman authored
      Summary:
      - Add the balance of the TTG extensions for hsSyn/HsBinds
      
      - Move all the (now orphan) data instances into hsSyn/HsInstances and
      use TTG Data instances Plan B
      https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/Instances#PLANB
      
      Updates haddock submodule.
      
      Illustrative numbers
      
      Compiling HsInstances before using Plan B.
      
      Max residency ~ 5G
      <<ghc: 629,864,691,176 bytes, 5300 GCs,
             321075437/1087762592 avg/max bytes residency (23 samples),
             2953M in use, 0.000 INIT (0.000 elapsed),
             383.511 MUT (384.986 elapsed), 37.426 GC (37.444 elapsed) :ghc>>
      
      Using Plan B
      
      Max residency 1.1G
      
      <<ghc: 78,832,782,968 bytes, 2884 GCs,
             222140352/386470152 avg/max bytes residency (34 samples),
             1062M in use, 0.001 INIT (0.001 elapsed),
             56.612 MUT (62.917 elapsed), 32.974 GC (32.923 elapsed) :ghc>>
      
      Test Plan: ./validate
      
      Reviewers: shayan-najd, goldfire, bgamari
      
      Subscribers: goldfire, thomie, mpickering, carter
      
      Differential Revision: https://phabricator.haskell.org/D4581
      b1386942
  8. 11 Apr, 2018 1 commit
  9. 10 Apr, 2018 3 commits
  10. 09 Apr, 2018 2 commits
  11. 07 Apr, 2018 1 commit
    • Ryan Scott's avatar
      Fix #14238 by always pretty-printing visible tyvars · 718a0181
      Ryan Scott authored
      Summary:
      Before, GHC would never print visible tyvars in the absence
      of `-fprint-explicit-foralls`, which led to `:kind` displaying
      incorrect kinds in GHCi. The fix is simple—simply check beforehand
      if any of the type variable binders are required when deciding when
      to pretty-print them.
      
      Test Plan: make test TEST=T14238
      
      Reviewers: simonpj, goldfire, bgamari
      
      Subscribers: thomie, carter
      
      GHC Trac Issues: #14238
      
      Differential Revision: https://phabricator.haskell.org/D4564
      718a0181
  12. 06 Apr, 2018 1 commit
  13. 02 Apr, 2018 5 commits
    • Richard Eisenberg's avatar
      Fix #14991. · d8d4266b
      Richard Eisenberg authored
      It turns out that solveEqualities really does need to use simpl_top.
      I thought that solveWanteds would be enough, and no existing test
      case showed up the different. #14991 shows that we need simpl_top.
      Easy enough to fix.
      
      test case: dependent/should_compile/T14991
      d8d4266b
    • Richard Eisenberg's avatar
      Mark test as expected to pass. · ddf89557
      Richard Eisenberg authored
      This fixes the SplitWD "unexpected pass". This test was fixed
      by ef443820 and somehow fell
      through my validation cracks.
      ddf89557
    • Simon Peyton Jones's avatar
      SpecConstr: accommodate casts in value arguments · 5ab8094e
      Simon Peyton Jones authored
      This commit:
      
        commit fb050a33
        Author: Simon Peyton Jones <simonpj@microsoft.com>
        Date:   Thu Oct 12 11:00:19 2017 +0100
      
        Do not bind coercion variables in SpecConstr rules
      
      arranged to reject any SpecConstr call pattern that mentioned
      a coercion in the pattern.
      
      There was a good reason for that
      -- see Note [SpecConstr and casts] --
      but I didn't realise how important it was to accept patterns
      that mention casts in /terms/.  Trac #14936 showed this up.
      
      This patch just narrows the restriction to discard only
      the cases where the coercion is mentioned only in types.
      Fortunately that was pretty easy to do.
      5ab8094e
    • Simon Peyton Jones's avatar
      Allow unpacking of single-data-con GADTs · 9187d5fb
      Simon Peyton Jones authored
      Trac #14978 pointed out that single-constructor GADTs should be
      unpackable without trouble.
      
      Acutally I realise that even existentials should be unpackable
      too, but that's a bit more work, so it's not part of this patch.
      
      See Note [Unpacking GADTs and existentials] in MkId.
      9187d5fb
    • Richard Eisenberg's avatar
      Test #14884, #14969 · 07abff71
      Richard Eisenberg authored
      These were fixed by faec8d35
      
      test cases: typecheck/should_fail/T14884
                  ghci/scripts/T14969
      07abff71
  14. 01 Apr, 2018 1 commit
    • Richard Eisenberg's avatar
      Track type variable scope more carefully. · faec8d35
      Richard Eisenberg authored
      The main job of this commit is to track more accurately the scope
      of tyvars introduced by user-written foralls. For example, it would
      be to have something like this:
      
        forall a. Int -> (forall k (b :: k). Proxy '[a, b]) -> Bool
      
      In that type, a's kind must be k, but k isn't in scope. We had a
      terrible way of doing this before (not worth repeating or describing
      here, but see the old tcImplicitTKBndrs and friends), but now
      we have a principled approach: make an Implication when kind-checking
      a forall. Doing so then hooks into the existing machinery for
      preventing skolem-escape, performing floating, etc. This also means
      that we bump the TcLevel whenever going into a forall.
      
      The new behavior is done in TcHsType.scopeTyVars, but see also
      TcHsType.tc{Im,Ex}plicitTKBndrs, which have undergone significant
      rewriting. There are several Notes near there to guide you. Of
      particular interest there is that Implication constraints can now
      have skolems that are out of order; this situation is reported in
      TcErrors.
      
      A major consequence of this is a slightly tweaked process for type-
      checking type declarations. The new Note [Use SigTvs in kind-checking
      pass] in TcTyClsDecls lays it out.
      
      The error message for dependent/should_fail/TypeSkolEscape has become
      noticeably worse. However, this is because the code in TcErrors goes to
      some length to preserve pre-8.0 error messages for kind errors. It's time
      to rip off that plaster and get rid of much of the kind-error-specific
      error messages. I tried this, and doing so led to a lovely error message
      for TypeSkolEscape. So: I'm accepting the error message quality regression
      for now, but will open up a new ticket to fix it, along with a larger
      error-message improvement I've been pondering. This applies also to
      dependent/should_fail/{BadTelescope2,T14066,T14066e}, polykinds/T11142.
      
      Other minor changes:
       - isUnliftedTypeKind didn't look for tuples and sums. It does now.
      
       - check_type used check_arg_type on both sides of an AppTy. But the left
         side of an AppTy isn't an arg, and this was causing a bad error message.
         I've changed it to use check_type on the left-hand side.
      
       - Some refactoring around when we print (TYPE blah) in error messages.
         The changes decrease the times when we do so, to good effect.
         Of course, this is still all controlled by
         -fprint-explicit-runtime-reps
      
      Fixes #14066 #14749
      
      Test cases: dependent/should_compile/{T14066a,T14749},
                  dependent/should_fail/T14066{,c,d,e,f,g,h}
      faec8d35
  15. 31 Mar, 2018 1 commit
  16. 27 Mar, 2018 2 commits
  17. 26 Mar, 2018 2 commits
    • alexvieth's avatar
      Fix performance of flattener patch (#12919) · b47a6c3a
      alexvieth authored
      This patch, authored by alexvieth and reviewed at D4451,
      makes performance improvements by critically optimizing parts
      of the flattener.
      
      Summary:
      T3064, T5321FD, T5321Fun, T9872a, T9872b, T9872c all pass.
      T9872a and T9872c show improvements beyond the -5% threshold.
      T9872d fails at 10.9% increased allocations.
      b47a6c3a
    • Richard Eisenberg's avatar
      Fix #12919 by making the flattener homegeneous. · e3dbb44f
      Richard Eisenberg authored
      This changes a key invariant of the flattener. Previously,
      flattening a type meant flattening its kind as well. But now,
      flattening is always homogeneous -- that is, the kind of the
      flattened type is the same as the kind of the input type.
      This is achieved by various wizardry in the TcFlatten.flatten_many
      function, as described in Note [flatten_many].
      
      There are several knock-on effects, including some refactoring
      in the canonicalizer to take proper advantage of the flattener's
      changed behavior. In particular, the tyvar case of can_eq_nc' no
      longer needs to take casts into account.
      
      Another effect is that flattening a tyconapp might change it
      into a casted tyconapp. This might happen if the result kind
      of the tycon contains a variable, and that variable changes
      during flattening. Because the flattener is homogeneous, it tacks
      on a cast to keep the tyconapp kind the same. However, this
      is problematic when flattening CFunEqCans, which need to have
      an uncasted tyconapp on the LHS and must remain homogeneous.
      The solution is a more involved canCFunEqCan, described in
      Note [canCFunEqCan].
      
      This patch fixes #13643 (as tested in typecheck/should_compile/T13643)
      and the panic in typecheck/should_compile/T13822 (as reported in #14024).
      Actually, there were two bugs in T13822: the first was just some
      incorrect logic in tryFill (part of the unflattener) -- also fixed
      in this patch -- and the other was the main bug fixed in this ticket.
      
      The changes in this patch exposed a long-standing flaw in OptCoercion,
      in that breaking apart an AppCo sometimes has unexpected effects on
      kinds. See new Note [EtaAppCo] in OptCoercion, which explains the
      problem and fix.
      
      Also here is a reversion of the major change in
      09bf135a, affecting ctEvCoercion.
      It turns out that making the flattener homogeneous changes the
      invariants on the algorithm, making the change in that patch
      no longer necessary.
      
      This patch also fixes:
        #14038 (dependent/should_compile/T14038)
        #13910 (dependent/should_compile/T13910)
        #13938 (dependent/should_compile/T13938)
        #14441 (typecheck/should_compile/T14441)
        #14556 (dependent/should_compile/T14556)
        #14720 (dependent/should_compile/T14720)
        #14749 (typecheck/should_compile/T14749)
      
      Sadly, this patch negatively affects performance of type-family-
      heavy code. The following patch fixes these performance degradations.
      However, the performance fixes are somewhat invasive and so I've
      kept them as a separate patch, labeling this one as [skip ci] so
      that validation doesn't fail on the performance cases.
      e3dbb44f