[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 17 commits: configure: Derive library version from ghc-prim.cabal.in
Marge Bot (@marge-bot)
gitlab at gitlab.haskell.org
Tue Aug 8 16:54:54 UTC 2023
Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC
Commits:
01961be3 by Ben Gamari at 2023-08-08T02:47:14-04:00
configure: Derive library version from ghc-prim.cabal.in
Since ghc-prim.cabal is now generated by Hadrian, we cannot depend upon
it.
Closes #23726.
- - - - -
3b373838 by Ryan Scott at 2023-08-08T02:47:49-04:00
tcExpr: Push expected types for untyped TH splices inwards
In !10911, I deleted a `tcExpr` case for `HsUntypedSplice` in favor of a much
simpler case that simply delegates to `tcApp`. Although this passed the test
suite at the time, this was actually an error, as the previous `tcExpr` case
was critically pushing the expected type inwards. This actually matters for
programs like the one in #23796, which GHC would not accept with type inference
alone—we need full-blown type _checking_ to accept these.
I have added back the previous `tcExpr` case for `HsUntypedSplice` and now
explain why we have two different `HsUntypedSplice` cases (one in `tcExpr` and
another in `splitHsApps`) in `Note [Looking through Template Haskell splices in
splitHsApps]` in `GHC.Tc.Gen.Head`.
Fixes #23796.
- - - - -
a49af1ff by Sebastian Graf at 2023-08-08T12:54:41-04:00
Cleanup a TODO introduced in 1f94e0f7
The change must have slipped through review of !4412
- - - - -
b1a58bf9 by Sebastian Graf at 2023-08-08T12:54:41-04:00
More explicit strictness in GHC.Real
- - - - -
1d15a546 by Sebastian Graf at 2023-08-08T12:54:41-04:00
exprIsTrivial: Factor out shared implementation
The duplication between `exprIsTrivial` and `getIdFromTrivialExpr_maybe` has
been bugging me for a long time.
This patch introduces an inlinable worker function `trivial_expr_fold` acting
as the single, shared decision procedure of triviality. It "returns" a
Church-encoded `Maybe (Maybe Id)`, so when it is inlined, it fuses to similar
code as before.
(Better code, even, in the case of `getIdFromTrivialExpr` which presently
allocates a `Just` constructor that cancels away after this patch.)
- - - - -
7f0bc37b by Sebastian Graf at 2023-08-08T12:54:41-04:00
Simplify: Simplification of arguments in a single function
The Simplifier had a function `simplArg` that wasn't called in `rebuildCall`,
which seems to be the main way to simplify args. Hence I consolidated the code
path to call `simplArg`, too, renaming to `simplLazyArg`.
- - - - -
1bfcbc88 by Sebastian Graf at 2023-08-08T12:54:41-04:00
Core.Ppr: Omit case binder for empty case alternatives
A minor improvement to pretty-printing
- - - - -
2fd29c4f by Sebastian Graf at 2023-08-08T12:54:41-04:00
Disable test RepPolyWrappedVar2 in JS backend
- - - - -
22c9aa2c by Sebastian Graf at 2023-08-08T12:54:41-04:00
Inlining literals into boring contexts is OK
- - - - -
6912d8f0 by Sebastian Graf at 2023-08-08T12:54:41-04:00
Clarify floating of unsafeEqualityProofs (#23754)
- - - - -
4e6e25a4 by Sebastian Graf at 2023-08-08T12:54:41-04:00
Kill SetLevel.notWorthFloating.is_triv (#23270)
We have had it since b84ba676034, when it operated on annotated expressions.
Nowadays it operates on vanilla `CoreExpr` though, so we should just call
`exprIsTrivial`; thus handling empty cases and string literals correctly.
- - - - -
a6b1185f by Sebastian Graf at 2023-08-08T12:54:41-04:00
ANFise string literal arguments (#23270)
This instates the invariant that a trivial CoreExpr translates to an atomic
StgExpr. Nice.
Annoyingly, in -O0 we sometimes generate
```
foo = case "blah"# of sat { __DEFAULT -> unpackCString# sat }
```
which makes it a bit harder to spot that we can emit a standard
`stg_unpack_cstring` thunk.
Fixes #23270.
- - - - -
b3bdf744 by Sebastian Graf at 2023-08-08T12:54:41-04:00
Deactivate -fcatch-nonexhaustive-cases in ghc-bignum (#23345)
- - - - -
127aaec6 by Sebastian Graf at 2023-08-08T12:54:41-04:00
CorePrep: Eliminate EmptyCase and unsafeEqualityProof in CoreToStg instead
We eliminate EmptyCase by way of `coreToStg (Case e _ _ []) = coreToStg e` now.
The main reason is that it plays far better in conjunction with eta expansion
(as we aim to do for arguments in CorePrep, #23083), because we can discard
any arguments, `(case e of {}) eta == case e of {}`, whereas in `(e |> co) eta`
it's impossible to discard the argument.
We do also give the same treatment to unsafeCoerce proofs and treat them as
trivial iff their RHS is trivial.
It is also both much simpler to describe than the previous mechanism of emitting
an unsafe coercion and simpler to implement, removing quite a bit of commentary
and `CorePrepProv`.
In the ghc/alloc perf test `LargeRecord`, we introduce an additional Simplifier
iteration due to #17910. E.g., FloatOut produces a binding
```
lvl_s6uK [Occ=Once1] :: GHC.Types.Int
[LclId]
lvl_s6uK = GHC.Types.I# 2#
lvl_s6uL [Occ=Once1] :: GHC.Types.Any
[LclId]
lvl_s6uL
= case Unsafe.Coerce.unsafeEqualityProof ... of
{ Unsafe.Coerce.UnsafeRefl v2_i6tr -> lvl_s6uK `cast` (... v2_i6tr ...)
}
```
That occurs once and hence is pre-inlined unconditionally in the next Simplifier
pass. It's non-trivial to find a way around that, but not really harmful
otherwise. Hence we accept a 1.2% increase on some architectures.
Metric Increase:
LargeRecord
- - - - -
b161389d by Sebastian Graf at 2023-08-08T12:54:41-04:00
CorePrep: Eta expand arguments (#23083)
Previously, we'd only eta expand let bindings and lambdas,
now we'll also eta expand arguments such as in T23083:
```hs
g f h = f (h `seq` (h $))
```
Unless `-fpedantic-bottoms` is set, we'll now transform to
```hs
g f h = f (\eta -> h eta)
```
in CorePrep.
See the new `Note [Eta expansion of arguments in CorePrep]` for the details.
We only do this optimisation with -O2 because we saw 2-3% ghc/alloc regressions
in T4801 and T5321FD.
Fixes #23083.
- - - - -
fd506230 by sheaf at 2023-08-08T12:54:48-04:00
Compute all emitted diagnostic codes
This commit introduces in GHC.Types.Error.Codes the function
constructorCodes :: forall diag. (...) => Map DiagnosticCode String
which computes a collection of all the diagnostic codes that correspond
to a particular type. In particular, we can compute the collection of
all diagnostic codes emitted by GHC using the invocation
constructorCodes @GhcMessage
We then make use of this functionality in the new "codes" test which
checks consistency and coverage of GHC diagnostic codes.
It performs three checks:
- check 1: all non-outdated GhcDiagnosticCode equations
are statically used.
- check 2: all outdated GhcDiagnosticCode equations
are statically unused.
- check 3: all statically used diagnostic codes are covered by
the testsuite (modulo accepted exceptions).
- - - - -
2c4f3f66 by Alan Zimmerman at 2023-08-08T12:54:49-04:00
EPA: Remove Location from WarningTxt source
This is not needed.
- - - - -
30 changed files:
- compiler/GHC/Core.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/Arity.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify/Iteration.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Ppr.hs
- compiler/GHC/Core/TyCo/FVs.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/TyCo/Subst.hs
- compiler/GHC/Core/TyCo/Tidy.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/CoreToStg.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Driver/Config/CoreToStg/Prep.hs
- compiler/GHC/Driver/DynFlags.hs
- compiler/GHC/Driver/Errors/Ppr.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/HsToCore/Errors/Ppr.hs
- compiler/GHC/Iface/Errors/Ppr.hs
- compiler/GHC/Iface/Make.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/Iface/Type.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3c9a5c12c7bd14ebb6f8f348e5857aa61b7bb6a8...2c4f3f66ca75a9e77ecb0982eef408ea655db50b
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3c9a5c12c7bd14ebb6f8f348e5857aa61b7bb6a8...2c4f3f66ca75a9e77ecb0982eef408ea655db50b
You're receiving this email because of your account on gitlab.haskell.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-commits/attachments/20230808/bfae7026/attachment-0001.html>
More information about the ghc-commits
mailing list