[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 11 commits: Fix `instance Bounded a => Bounded (Down a)` (#18716)

Marge Bot gitlab at gitlab.haskell.org
Tue Oct 27 11:39:35 UTC 2020 


 Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC


Commits:
76978387 by David Beacham at 2020-10-27T07:39:21-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

- - - - -
24f25a68 by Vladislav Zavialov at 2020-10-27T07:39:21-04:00
Version bump: base-4.16 (#18712)

Also bumps upper bounds on base in boot libraries (incl. submodules).

- - - - -
780fc2c7 by Tamar Christina at 2020-10-27T07:39:23-04:00
winio: simplify logic remove optimization step.

- - - - -
3ed10dbc by Ben Gamari at 2020-10-27T07:39:23-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.

- - - - -
96a2aaa4 by Ben Gamari at 2020-10-27T07:39:24-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.

- - - - -
fbfe5c57 by Simon Peyton Jones at 2020-10-27T07:39:24-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

- - - - -
ab8d477f by Sergei Trofimovich at 2020-10-27T07:39:25-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>

- - - - -
cd25e4d8 by David Eichmann at 2020-10-27T07:39:27-04:00
Use config.run_ways for multi_compile_and_run tests

- - - - -
ccc2a455 by Alan Zimmerman at 2020-10-27T07:39:27-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'

- - - - -
d100e97f by Ben Gamari at 2020-10-27T07:39:27-04:00
gitlab-ci: Bump ci-images

Bumps bootstrap compiler to 8.10.1.

- - - - -
d1d0a099 by Sebastian Graf at 2020-10-27T07:39:27-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%
```

- - - - -


30 changed files:

- .gitlab-ci.yml
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/FamInstEnv.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/Unify.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/Annotation.hs
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Tc/Solver.hs
- compiler/GHC/Tc/Solver/Flatten.hs
- compiler/GHC/Types/Demand.hs
- compiler/ghc.cabal.in
- ghc.mk
- hadrian/hadrian.cabal
- hadrian/src/Builder.hs
- hadrian/src/Rules/Clean.hs
- libraries/array
- libraries/base/Data/Ord.hs
- libraries/base/GHC/Event/Windows.hsc
- libraries/base/base.cabal
- libraries/base/changelog.md
- libraries/deepseq
- libraries/directory
- libraries/filepath
- libraries/ghc-boot-th/ghc-boot-th.cabal.in
- libraries/ghc-boot/ghc-boot.cabal.in
- libraries/ghc-compact/ghc-compact.cabal
- libraries/ghci/ghci.cabal.in
- libraries/haskeline


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/ba4fd2104e95ee6632e421255b98606c03de23d0...d1d0a09920c69ff9c4a197defc9d0e03b051f809

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/ba4fd2104e95ee6632e421255b98606c03de23d0...d1d0a09920c69ff9c4a197defc9d0e03b051f809
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/5bad0102/attachment-0001.html>

More information about the ghc-commits mailing list