[Git][ghc/ghc][wip/ghc-11342-char-kind] 12 commits: Fix `instance Bounded a => Bounded (Down a)` (#18716)
Danya Rogozin
gitlab at gitlab.haskell.org
Tue Oct 27 18:55:33 UTC 2020
Danya Rogozin pushed to branch wip/ghc-11342-char-kind at Glasgow Haskell Compiler / GHC
Commits:
9ad51bc9 by David Beacham at 2020-10-27T13:59:35-04:00
Fix `instance Bounded a => Bounded (Down a)` (#18716)
* Flip `minBound` and `maxBound` to respect the change in ordering
* Remove awkward `Enum` (and hence `Integral`) instances for
`Data.Ord.Down`
* Update changelog
- - - - -
eedec53d by Vladislav Zavialov at 2020-10-27T14:00:11-04:00
Version bump: base-4.16 (#18712)
Also bumps upper bounds on base in boot libraries (incl. submodules).
- - - - -
412018c1 by Tamar Christina at 2020-10-27T14:00:49-04:00
winio: simplify logic remove optimization step.
- - - - -
4950dd07 by Ben Gamari at 2020-10-27T14:01:24-04:00
hadrian: Suppress xelatex output unless it fails
As noted in #18835, xelatex produces an absurd amount of output, nearly
all of which is meaningless. Silence this.
Fixes #18835.
- - - - -
f3d8ab2e by Ben Gamari at 2020-10-27T14:02:00-04:00
build system: Clean mingw tarballs
Tamar noticed in !4293 that the build systems fail to clean up the mingw
tarballs directory (`ghc-tarballs`). Fix this in both the make build
system and Hadrian.
- - - - -
0b3d23af by Simon Peyton Jones at 2020-10-27T14:02:34-04:00
Fix two constraint solving problems
This patch fixes two problems in the constraint solver.
* An actual bug #18555: we were floating out a constraint to eagerly,
and that was ultimately fatal. It's explained in
Note [Do not float blocked constraints] in GHC.Core.Constraint.
This is all very delicate, but it's all going to become irrelevant
when we stop floating constraints (#17656).
* A major performance infelicity in the flattener. When flattening
(ty |> co) we *never* generated Refl, even when there was nothing
at all to do. Result: we would gratuitously rewrite the constraint
to exactly the same thing, wasting work. Described in #18413, and
came up again in #18855.
Solution: exploit the special case by calling the new function
castCoercionKind1. See Note [castCoercionKind1] in
GHC.Core.Coercion
- - - - -
f76c5a08 by Sergei Trofimovich at 2020-10-27T14:03:14-04:00
ghc.mk: amend 'make sdist'
Noticed 'make sdist' failure seen as:
```
"rm" -rf sdistprep/ghc/ghc-9.1.0.20201020/hadrian/_build/ (SRC_DIST_GHC_DIR)/hadrian/dist-newstyle/
/bin/sh: -c: line 0: syntax error near unexpected token `('
```
commit 9657f6f34
("sdist: Include hadrian sources in source distribution")
added a new cleanup path without a variable expantion.
The change adds variable reference. While at it move directory
cleanup to a separate statement.
Amends #18794
Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org>
- - - - -
78b52c88 by David Eichmann at 2020-10-27T14:03:51-04:00
Use config.run_ways for multi_compile_and_run tests
- - - - -
e3fdd419 by Alan Zimmerman at 2020-10-27T14:04:26-04:00
Api Annotations: Introduce AnnPercent for HsExplicitMult
For the case
foo :: a %p -> b
The location of the '%' is captured, separate from the 'p'
- - - - -
d2a25f42 by Ben Gamari at 2020-10-27T14:05:02-04:00
gitlab-ci: Bump ci-images
Bumps bootstrap compiler to 8.10.1.
- - - - -
28f98b01 by Sebastian Graf at 2020-10-27T14:05:37-04:00
DmdAnal: Kill `is_thunk` case in `splitFV`
The `splitFV` function implements the highly dubious hack
described in `Note [Lazy und unleashable free variables]` in
GHC.Core.Opt.DmdAnal. It arranges it so that demand signatures only
carry strictness info on free variables. Usage info is released through
other means, see the Note. It's purely for analysis performance reasons.
It turns out that `splitFV` has a quite involved case for thunks that
produces slightly different usage signatures and it's not clear why we
need it: `splitFV` is only relevant in the LetDown case and the only
time we call it on thunks is for top-level or local recursive thunks.
Since usage signatures of top-level thunks can only reference other
top-level bindings and we completely discard demand info we have on
top-level things (see the lack of `setIdDemandInfo` in
`dmdAnalTopBind`), the `is_thunk` case is completely irrelevant here.
For local, recursive thunks, the added benefit of the `is_thunk` test
is marginal: We get used-multiple-times in some cases where previously
we had used-once if a recursive thunk has multiple call sites. It's
very unlikely and not a case to optimise for.
So we kill the `is_thunk` case and inline `splitFV` at its call site,
exposing `isWeakDmd` from `GHC.Types.Demand` instead.
The NoFib summary supports this decision:
```
Min 0.0% -0.0%
Max 0.0% +0.0%
Geometric Mean -0.0% -0.0%
```
- - - - -
d1688d5a by Daniel Rogozin at 2020-10-27T21:55:04+03:00
the char kind: type families, functionality, and submodule updates
Co-authored-by: Rinat Stryungis <rinat.stryungis at serokell.io>
Metric Decrease:
T5205
Metric Increase:
Naperian
T13035
- - - - -
30 changed files:
- .gitlab-ci.yml
- compiler/GHC/Builtin/Names.hs
- compiler/GHC/Builtin/Names/TH.hs
- compiler/GHC/Builtin/Types.hs-boot
- compiler/GHC/Builtin/Types/Literals.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/FamInstEnv.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Map.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unify.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/Data/FastString.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/HsToCore/Binds.hs
- compiler/GHC/HsToCore/Quote.hs
- compiler/GHC/Iface/Type.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/Annotation.hs
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/HsType.hs
- compiler/GHC/StgToCmm/Closure.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Gen/Splice.hs
- compiler/GHC/Tc/Instance/Class.hs
- compiler/GHC/Tc/Instance/Typeable.hs
- compiler/GHC/Tc/Solver.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/da2e7af56e7aa1e7f6ddd9e5c1f546c4230c5927...d1688d5a8639338653e59e8591f3a3b90817d35f
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/da2e7af56e7aa1e7f6ddd9e5c1f546c4230c5927...d1688d5a8639338653e59e8591f3a3b90817d35f
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/20201027/76b4e2c7/attachment.html>
More information about the ghc-commits
mailing list