1. 02 May, 2022 1 commit
  2. 22 Apr, 2022 1 commit
    • Krzysztof Gogolewski's avatar
      Fixes to rubbish literals · f435d55f
      Krzysztof Gogolewski authored and  Marge Bot's avatar Marge Bot committed
      * In CoreToStg, the application 'RUBBISH[rep] x' was simplified
        to 'RUBBISH[rep]'. But it is possible that the result of the function
        is represented differently than the function.
      * In Unarise, 'LitRubbish (primRepToType prep)'
        is incorrect: LitRubbish takes a RuntimeRep such as IntRep,
        while primRepToType returns a type such as Any @(TYPE IntRep). Use
        primRepToRuntimeRep instead.
        This code is never run in the testsuite.
      * In StgToByteCode, all rubbish literals were assumed to be boxed.
        This code predates representation-polymorphic RubbishLit and I think
        it was not updated.
      I don't have a testcase for any of those issues, but the code looks
  3. 02 Mar, 2022 1 commit
    • doyougnu's avatar
      GenStgAlt 3-tuple synonym --> Record type · 91a10cb0
      doyougnu authored and  Marge Bot's avatar Marge Bot committed
      This commit alters GenStgAlt from a type synonym to a Record with field
      accessors. In pursuit of #21078, this is not a required change but cleans
      up several areas for nicer code in the upcoming js-backend, and in GHC
      GenStgAlt: 3-tuple -> record
      Stg.Utils: GenStgAlt 3-tuple -> record
      Stg.Stats: StgAlt 3-tuple --> record
      Stg.InferTags.Rewrite: StgAlt 3-tuple -> record
      Stg.FVs: GenStgAlt 3-tuple -> record
      Stg.CSE: GenStgAlt 3-tuple -> record
      Stg.InferTags: GenStgAlt 3-tuple --> record
      Stg.Debug: GenStgAlt 3-tuple --> record
      Stg.Lift.Analysis: GenStgAlt 3-tuple --> record
      Stg.Lift: GenStgAlt 3-tuple --> record
      ByteCode.Instr: GenStgAlt 3-tuple --> record
      Stg.Syntax: add GenStgAlt helper functions
      Stg.Unarise: GenStgAlt 3-tuple --> record
      Stg.BcPrep: GenStgAlt 3-tuple --> record
      CoreToStg: GenStgAlt 3-tuple --> record
      StgToCmm.Expr: GenStgAlt 3-tuple --> record
      StgToCmm.Bind: GenStgAlt 3-tuple --> record
      StgToByteCode: GenStgAlt 3-tuple --> r...
  4. 12 Feb, 2022 1 commit
    • Andreas Klebinger's avatar
      Tag inference work. · 0e93023e
      Andreas Klebinger authored and Matthew Pickering's avatar Matthew Pickering committed
      This does three major things:
      * Enforce the invariant that all strict fields must contain tagged
      * Try to predict the tag on bindings in order to omit tag checks.
      * Allows functions to pass arguments unlifted (call-by-value).
      The former is "simply" achieved by wrapping any constructor allocations with
      a case which will evaluate the respective strict bindings.
      The prediction is done by a new data flow analysis based on the STG
      representation of a program. This also helps us to avoid generating
      redudant cases for the above invariant.
      StrictWorkers are created by W/W directly and SpecConstr indirectly.
      See the Note [Strict Worker Ids]
      Other minor changes:
      * Add StgUtil module containing a few functions needed by, but
        not specific to the tag analysis.
      Metric Decrease:
      Metric Increase:
  5. 06 Feb, 2022 1 commit
  6. 31 Jan, 2022 1 commit
    • doyougnu's avatar
      StgToCmm: decouple DynFlags, add StgToCmmConfig · 60a54a8f
      doyougnu authored and  Marge Bot's avatar Marge Bot committed
      StgToCmm: add Config, remove CgInfoDownwards
      StgToCmm: runC api change to take StgToCmmConfig
      StgToCmm: CgInfoDownad -> StgToCmmConfig
      StgToCmm.Monad: update getters/setters/withers
      StgToCmm: remove CallOpts in StgToCmm.Closure
      StgToCmm: remove dynflag references
      StgToCmm: PtrOpts removed
      StgToCmm: add TMap to config, Prof - dynflags
      StgToCmm: add omit yields to config
      StgToCmm.ExtCode: remove redundant import
      StgToCmm.Heap: remove references to dynflags
      StgToCmm: codeGen api change, DynFlags -> Config
      StgToCmm: remove dynflags in Env and StgToCmm
      StgToCmm.DataCon: remove dynflags references
      StgToCmm: remove dynflag references in DataCon
      StgToCmm: add backend avx flags to config
      StgToCmm.Prim: remove dynflag references
      StgToCmm.Expr: remove dynflag references
      StgToCmm.Bind: remove references to dynflags
      StgToCmm: move DoAlignSanitisation to Cmm.Type
      StgToCmm: remove PtrOpts in Cmm.Parser.y
      DynFlags: update ipInitCode api
      StgToCmm: Config Module is single source of truth
      StgToCmm: Lazy config breaks IORef deadlock
      testsuite: bump countdeps threshold
      StgToCmm.Config: strictify fields except UpdFrame
      Strictifying UpdFrameOffset causes the RTS build with stage1 to
      deadlock. Additionally, before the deadlock performance of the RTS
      is noticeably slower.
      StgToCmm.Config: add field descriptions
      StgToCmm: revert strictify on Module in config
      testsuite: update CountDeps tests
      StgToCmm: update comment, fix exports
      Specifically update comment about loopification passed into dynflags
      then stored into stgToCmmConfig. And remove getDynFlags from
      Monad.hs exports
      Types.Name: add pprFullName function
      StgToCmm.Ticky: use pprFullname, fixup ExtCode imports
      Cmm.Info: revert cmmGetClosureType removal
      StgToCmm.Bind: use pprFullName, Config update comments
      StgToCmm: update closureDescription api
      StgToCmm: SAT altHeapCheck
      StgToCmm: default render for Info table, ticky
      Use default rendering contexts for info table and ticky ticky, which should be independent of command line input.
      testsuite: bump count deps
      pprFullName: flag for ticky vs normal style output
      convertInfoProvMap: remove unused parameter
      StgToCmm.Config: add backend flags to config
      StgToCmm.Config: remove Backend from Config
      StgToCmm.Prim: refactor Backend call sites
      StgToCmm.Prim: remove redundant imports
      StgToCmm.Config: refactor vec compatibility check
      StgToCmm.Config: add allowQuotRem2 flag
      StgToCmm.Ticky: print internal names with parens
      StgToCmm.Bind: dispatch ppr based on externality
      StgToCmm: Add pprTickyname, Fix ticky naming
      Accidently removed the ctx for ticky SDoc output. The only relevant flag
      is sdocPprDebug which was accidental set to False due to using
      defaultSDocContext without altering the flag.
      StgToCmm: remove stateful fields in config
      fixup: config: remove redundant imports
      StgToCmm: move Sequel type to its own module
      StgToCmm: proliferate getCallMethod updated api
      StgToCmm.Monad: add FCodeState to Monad Api
      StgToCmm: add second reader monad to FCode
      fixup: Prim.hs: missed a merge conflict
      fixup: Match countDeps tests to HEAD
      StgToCmm.Monad: withState -> withCgState
      To disambiguate it from mtl withState. This withState shouldn't be
      returning the new state as a value. However, fixing this means tackling
      the knot tying in CgState and so is very difficult since it changes when
      the thunk of the knot is forced which either leads to deadlock or to
      compiler panic.
  7. 12 Jan, 2022 1 commit
  8. 11 Sep, 2021 1 commit
    • Sylvain Henry's avatar
      Canonicalize bignum literals · 089de88e
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      Before this patch Integer and Natural literals were desugared into "real"
      Core in Core prep. Now we desugar them directly into their final ConApp
      form in HsToCore. We only keep the double representation for BigNat#
      (literals larger than a machine Word/Int) which are still desugared in
      Core prep.
      Using the final form directly allows case-of-known-constructor to fire
      for bignum literals, fixing #20245.
      Slight increase (+2.3) in T4801 which is a pathological case with
      Integer literals.
      Metric Increase:
  9. 21 Jul, 2021 1 commit
  10. 22 Jun, 2021 1 commit
    • Sylvain Henry's avatar
      Put tracing functions into their own module · 14956cb8
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      Now that Outputable is independent of DynFlags, we can put tracing
      functions using SDocs into their own module that doesn't transitively
      depend on any GHC.Driver.* module.
      A few modules needed to be moved to avoid loops in DEBUG mode.
  11. 05 Jun, 2021 1 commit
    • Simon Peyton Jones's avatar
      Re-do rubbish literals · 52a524f7
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      As #19882 pointed out, we were simply doing rubbish literals wrong.
      (I'll refrain from explaining the wrong-ness here -- see the ticket.)
      This patch fixes it by adding a Type (of kind RuntimeRep) as field of
      LitRubbish, rather than [PrimRep].
      The Note [Rubbish literals] in GHC.Types.Literal explains the details.
  12. 20 May, 2021 1 commit
  13. 13 May, 2021 3 commits
    • Sylvain Henry's avatar
      Remove useless {-# LANGUAGE CPP #-} pragmas · 67a5a91e
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
    • Sylvain Henry's avatar
      Fully remove HsVersions.h · 0ef11907
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      Replace uses of WARN macro with calls to:
        warnPprTrace :: Bool -> SDoc -> a -> a
      Remove the now unused HsVersions.h
      Bump haddock submodule
    • Sylvain Henry's avatar
      Replace CPP assertions with Haskell functions · bfabf94f
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      There is no reason to use CPP. __LINE__ and __FILE__ macros are now
      better replaced with GHC's CallStack. As a bonus, assert error messages
      now contain more information (function name, column).
      Here is the mapping table (HasCallStack omitted):
        * ASSERT:   assert     :: Bool -> a -> a
        * MASSERT:  massert    :: Bool -> m ()
        * ASSERTM:  assertM    :: m Bool -> m ()
        * ASSERT2:  assertPpr  :: Bool -> SDoc -> a -> a
        * MASSERT2: massertPpr :: Bool -> SDoc -> m ()
        * ASSERTM2: assertPprM :: m Bool -> SDoc -> m ()
  14. 12 May, 2021 1 commit
    • Simon Peyton Jones's avatar
      Fix strictness and arity info in SpecConstr · c7717949
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      In GHC.Core.Opt.SpecConstr.spec_one we were giving join-points an
      incorrect join-arity -- this was fallout from
          commit c71b2204
          Author: Simon Peyton Jones <simonpj@microsoft.com>
          Date:   Thu Apr 8 23:36:24 2021 +0100
              Improvements in SpecConstr
              * Allow under-saturated calls to specialise
                See Note [SpecConstr call patterns]
                This just allows a bit more specialisation to take place.
      and showed up in #19780. I refactored the code to make the new
      function calcSpecInfo which treats join points separately.
      In doing this I discovered two other small bugs:
      * In the Var case of argToPat we were treating UnkOcc as
        uninteresting, but (by omission) NoOcc as interesting. As a
        result we were generating SpecConstr specialisations for functions
        with unused arguments.  But the absence anlyser does that much
        better; doing it here just generates more code.  Easily fixed.
      * The lifted/unlifted test in GHC.Core.Opt.WorkWrap.Utils.mkWorkerArgs
        was back to front (#19794).  Easily fixed.
      * In the same function, mkWorkerArgs, we were adding an extra argument
        nullary join points, which isn't necessary.  I added a test for
        this.  That in turn meant I had to remove an ASSERT in
        CoreToStg.mkStgRhs for nullary join points, which was always bogus
        but now trips; I added a comment to explain.
  15. 27 Apr, 2021 1 commit
    • Simon Peyton Jones's avatar
      Eliminate unsafeEqualityProof in CorePrep · 6c7fff0b
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      The main idea here is to avoid treating
        * case e of {}
        * case unsafeEqualityProof of UnsafeRefl co -> blah
      specially in CoreToStg.  Instead, nail them in CorePrep,
      by converting
         case e of {}
           ==>   e |> unsafe-co
         case unsafeEqualityProof of UnsafeRefl cv -> blah
           ==> blah[unsafe-co/cv]
      in GHC.Core.Prep.  Now expressions that we want to treat as trivial
      really are trivial.  We can get rid of cpExprIsTrivial.
      And we fix #19700.
      A downside is that, at least under unsafeEqualityProof, we substitute
      in types and coercions, which is more work. But a big advantage is
      that it's all very simple and principled: CorePrep really gets rid of
      the unsafeCoerce stuff, as it does empty case, runRW#, lazyId etc.
      I've updated the overview in GHC.Core.Prep, and added
        Note [Unsafe coercions] in GHC.Core.Prep
        Note [Implementing unsafeCoerce] in base:Unsafe.Coerce
      We get 3% fewer bytes allocated when compiling perf/compiler/T5631,
      which uses a lot of unsafeCoerces.  (It's a happy-generated parser.)
      Metric Decrease:
  16. 27 Mar, 2021 1 commit
    • Sebastian Graf's avatar
      Rubbish literals for all representations (#18983) · 57d21e6a
      Sebastian Graf authored and  Marge Bot's avatar Marge Bot committed
      This patch cleans up the complexity around WW's `mk_absent_let` by
      broadening the scope of `LitRubbish`. Rubbish literals now store the
      `PrimRep` they represent and are ultimately lowered in Cmm.
      This in turn allows absent literals of `VecRep` or `VoidRep`. The latter
      allows absent literals for unlifted coercions, as requested in #18983.
      I took the liberty to rewrite and clean up `Note [Absent fillers]` and
      `Note [Rubbish values]` to account for the new implementation and to
      make them more orthogonal in their description.
      I didn't add a new regression test, as `T18982` already contains the
      test in the ticket and its test output changes as expected.
      Fixes #18983.
  17. 20 Mar, 2021 5 commits
  18. 14 Mar, 2021 1 commit
    • Sebastian Graf's avatar
      Implement the UnliftedDatatypes extension · b73c9c5f
      Sebastian Graf authored and  Marge Bot's avatar Marge Bot committed
      GHC Proposal: 0265-unlifted-datatypes.rst
      Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/265
      Issues: #19523
      Implementation Details: Note [Implementation of UnliftedDatatypes]
      This patch introduces the `UnliftedDatatypes` extension. When this extension is
      enabled, GHC relaxes the restrictions around what result kinds are allowed in
      data declarations. This allows data types for which an unlifted or
      levity-polymorphic result kind is inferred.
      The most significant changes are in `GHC.Tc.TyCl`, where
      `Note [Implementation of UnliftedDatatypes]` describes the details of the
      Fixes #19523.
  19. 03 Mar, 2021 2 commits
    • Matthew Pickering's avatar
      Add option to give each usage of a data constructor its own info table · a7aac008
      Matthew Pickering authored
      The `-fdistinct-constructor-tables` flag will generate a fresh info
      table for the usage of any data constructor. This is useful for
      debugging as now by inspecting the info table, you can determine which
      usage of a constructor caused that allocation rather than the old
      situation where the info table always mapped to the definition site of
      the data constructor which is useless.
      In conjunction with `-hi` and `-finfo-table-map` this gives a more fine
      grained understanding of where constructor allocations arise from in a
    • Matthew Pickering's avatar
      Add -finfo-table-map which maps info tables to source positions · 4b297979
      Matthew Pickering authored
      This new flag embeds a lookup table from the address of an info table
      to information about that info table.
      The main interface for consulting the map is the `lookupIPE` C function
      > InfoProvEnt * lookupIPE(StgInfoTable *info)
      The `InfoProvEnt` has the following structure:
      > typedef struct InfoProv_{
      >     char * table_name;
      >     char * closure_desc;
      >     char * ty_desc;
      >     char * label;
      >     char * module;
      >     char * srcloc;
      > } InfoProv;
      > typedef struct InfoProvEnt_ {
      >     StgInfoTable * info;
      >     InfoProv prov;
      >     struct InfoProvEnt_ *link;
      > } InfoProvEnt;
      The source positions are approximated in a similar way to the source
      positions for DWARF debugging information. They are only approximate but
      in our experience provide a good enough hint about where the problem
      might be. It is therefore recommended to use this flag in conjunction
      with `-g<n>` for more accurate locations.
      The lookup table is also emitted into the eventlog when it is available
      as it is intended to be used with the `-hi` profiling mode.
      Using this flag will significantly increase the size of the resulting
      object file but only by a factor of 2-3x in our experience.
  20. 01 Mar, 2021 1 commit
    • Simon Peyton Jones's avatar
      Fix terrible occurrence-analysis bug · 6429943b
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      Ticket #19360 showed up a terrible bug in the occurrence analyser,
      in a situation like this
         Rec { f = g
             ; g = ..f...
               {-# RULE g .. = ...f... #-}  }
      Then f was postInlineUnconditionally, but not in the RULE (which
      is simplified first), so we had a RULE mentioning a variable that
      was not in scope.
      This led me to review (again) the subtle loop-breaker stuff in the
      occurrence analyser. The actual changes are few, and are largely
      simplifications.  I did a /lot/ of comment re-organising though.
      There was an unexpected amount of fallout.
      * Validation failed when compiling the stage2 compiler with profiling
        on. That turned to tickle a second latent bug in the same OccAnal
        code (at least I think it was always there), which led me to
        simplify still further; see Note [inl_fvs] in GHC.Core.Opt.OccurAnal.
      * But that in turn let me to some strange behaviour in CSE when ticks
        are in the picture, which I duly fixed.  See Note [Dealing with ticks]
        in GHC.Core.Opt.CSE.
      * Then I got an ASSERT failure in CoreToStg, which again seems to be
        a latent bug.  See Note [Ticks in applications] in GHC.CoreToStg
      * I also made one unforced change: I now simplify the RHS of a RULE in
        the same way as the RHS of a stable unfolding. This can allow a
        trivial binding to disappear sooner than otherwise, and I don't
        think it has any downsides.  The change is in
  21. 29 Jan, 2021 1 commit
    • Leif Metcalf's avatar
      Remove StgLam · 37378a0b
      Leif Metcalf authored and  Marge Bot's avatar Marge Bot committed
      StgLam is used exclusively in the work of CoreToStg, but there's nothing
      in the type of StgExpr that indicates this, so we're forced throughout
      the Stg.* codebase to handle cases like:
      case expr of
        StgLam lam -> panic "Unexpected StgLam"
      This patch removes the StgLam constructor from the base StgExpr so these
      cases no longer need to be handled. Instead, we use a new intermediate
      type in CoreToStg, PreStgRhs, to represent the RHS expression of a
  22. 22 Jan, 2021 1 commit
  23. 02 Jan, 2021 1 commit
    • Simon Peyton Jones's avatar
      Don't use absentError thunks for strict constructor fields · a8926e95
      Simon Peyton Jones authored and  Marge Bot's avatar Marge Bot committed
      This patch fixes #19133 by using LitRubbish for strict constructor
      fields, even if they are of lifted types.  Previously LitRubbish
      worked only for unlifted (but boxed) types.
      The change is very easy, although I needed a boolean field in
      LitRubbish to say whether or not it is lifted.  (That seemed easier
      than giving it another type argument.
      This is preparing for Andreas's work on establishing the invariant
      that strict constructor fields are always tagged and evaluated
      (see #16970).
      Meanwhile, nothing was actually wrong before, so there are no tests.
  24. 20 Nov, 2020 1 commit
    • Sebastian Graf's avatar
      Demand: Interleave usage and strictness demands (#18903) · 0aec78b6
      Sebastian Graf authored and  Marge Bot's avatar Marge Bot committed
      As outlined in #18903, interleaving usage and strictness demands not
      only means a more compact demand representation, but also allows us to
      express demands that we weren't easily able to express before.
      Call demands are *relative* in the sense that a call demand `Cn(cd)`
      on `g` says "`g` is called `n` times. *Whenever `g` is called*, the
      result is used according to `cd`". Example from #18903:
      h :: Int -> Int
      h m =
        let g :: Int -> (Int,Int)
            g 1 = (m, 0)
            g n = (2 * n, 2 `div` n)
            {-# NOINLINE g #-}
        in case m of
          1 -> 0
          2 -> snd (g m)
          _ -> uncurry (+) (g m)
      Without the interleaved representation, we would just get `L` for the
      strictness demand on `g`. Now we are able to express that whenever
      `g` is called, its second component is used strictly in denoting `g`
      by `1C1(P(1P(U),SP(U)))`. This would allow Nested CPR to unbox the
      division, for example.
      Fixes #18903.
      While fixing regressions, I also discovered and fixed #18957.
      Metric Decrease:
  25. 01 Nov, 2020 1 commit
  26. 04 Sep, 2020 1 commit
    • Ryan Scott's avatar
      Introduce isBoxedTupleDataCon and use it to fix #18644 · c1e54439
      Ryan Scott authored and  Marge Bot's avatar Marge Bot committed
      The code that converts promoted tuple data constructors to
      `IfaceType`s in `GHC.CoreToIface` was using `isTupleDataCon`, which
      conflates boxed and unboxed tuple data constructors. To avoid this,
      this patch introduces `isBoxedTupleDataCon`, which is like
      `isTupleDataCon` but only works for _boxed_ tuple data constructors.
      While I was in town, I was horribly confused by the fact that there
      were separate functions named `isUnboxedTupleCon` and
      `isUnboxedTupleTyCon` (similarly, `isUnboxedSumCon` and
      `isUnboxedSumTyCon`). It turns out that the former only works for
      data constructors, despite its very general name! I opted to rename
      `isUnboxedTupleCon` to `isUnboxedTupleDataCon` (similarly, I renamed
      `isUnboxedSumCon` to `isUnboxedSumDataCon`) to avoid this potential
      confusion, as well as to be more consistent with
      the naming convention I used for `isBoxedTupleDataCon`.
      Fixes #18644.
  27. 12 Aug, 2020 1 commit
    • Sylvain Henry's avatar
      DynFlags: disentangle Outputable · accbc242
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      - put panic related functions into GHC.Utils.Panic
      - put trace related functions using DynFlags in GHC.Driver.Ppr
      One step closer making Outputable fully independent of DynFlags.
      Bump haddock submodule
  28. 25 Jul, 2020 1 commit
  29. 21 Jul, 2020 1 commit
    • Sylvain Henry's avatar
      DynFlags: remove use of sdocWithDynFlags from GHC.Stg.* (#17957) · 30caeee7
      Sylvain Henry authored and  Marge Bot's avatar Marge Bot committed
      * add StgPprOpts datatype
      * remove Outputable instances for types that need `StgPprOpts` to be
        pretty-printed and explicitly call type specific ppr functions
      * add default `panicStgPprOpts` for panic messages (when it's not
        convenient to thread StgPprOpts or DynFlags down to the ppr function
  30. 17 Jun, 2020 1 commit
    • Sylvain Henry's avatar
      Update compiler · 96aa5787
      Sylvain Henry authored and Ben Gamari's avatar Ben Gamari committed
      Thanks to ghc-bignum, the compiler can be simplified:
      * Types and constructors of Integer and Natural can be wired-in. It
        means that we don't have to query them from interfaces. It also means
        that numeric literals don't have to carry their type with them.
      * The same code is used whatever ghc-bignum backend is enabled. In
        particular, conversion of bignum literals into final Core expressions
        is now much more straightforward. Bignum closure inspection too.
      * GHC itself doesn't depend on any integer-* package anymore
      * The `integerLibrary` setting is gone.
  31. 14 Jun, 2020 1 commit
    • Ben Gamari's avatar
      codeGen: Don't discard live case binders in unsafeEqualityProof logic · 9a7462fb
      Ben Gamari authored and  Marge Bot's avatar Marge Bot committed
      Previously CoreToStg would unconditionally discard cases of the form:
          case unsafeEqualityProof of wild { _ -> rhs }
      and rather replace the whole thing with `rhs`. However, in some cases
      (see #18227) the case binder is still live, resulting in unbound
      occurrences in `rhs`. Fix this by only discarding the case if the case
      binder is dead.
      Fixes #18227.
  32. 29 May, 2020 1 commit
    • Ben Gamari's avatar
      Eta expand un-saturated primops · 277c2f26
      Ben Gamari authored and  Marge Bot's avatar Marge Bot committed
      Now since we no longer try to predict CAFfyness we have no need for the
      solution to #16846. Eta expanding unsaturated primop applications is
      conceptually simpler, especially in the presence of levity polymorphism.
      This essentially reverts cac8dc9f,
      as suggested in #18079.
      Closes #18079.
  33. 24 May, 2020 1 commit