[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 10 commits: PmCheck: Adjust recursion depth for inhabitation test

Wed Apr 1 19:35:54 UTC 2020

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

Commits:
7b217179 by Sebastian Graf at 2020-04-01T15:03:24-04:00
PmCheck: Adjust recursion depth for inhabitation test

In #17977, we ran into the reduction depth limit of the typechecker.
That was only a symptom of a much broader issue: The recursion depth
of the coverage checker for trying to instantiate strict fields in the
`nonVoid` test was far too high (100, the `defaultMaxTcBound`).

As a result, we were performing quite poorly on `T17977`.
Short of a proper termination analysis to prove emptyness of a type,
we just arbitrarily default to a much lower recursion limit of 3.

Fixes #17977.

- - - - -
3c09f636 by Andreas Klebinger at 2020-04-01T15:03:59-04:00
Make hadrian pass on the no-colour setting to GHC.

Fixes #17983.

- - - - -
43608d6d by Simon Peyton Jones at 2020-04-01T15:35:25-04:00
Re-engineer the binder-swap transformation

The binder-swap transformation is implemented by the occurrence
analyser -- see Note [Binder swap] in OccurAnal. However it had
a very nasty corner in it, for the case where the case scrutinee
was a GlobalId.  This led to trouble and hacks, and ultimately
to #16296.

This patch re-engineers how the occurrence analyser implements
the binder-swap, by actually carrying out a substitution rather
than by adding a let-binding.  It's all described in
Note [The binder-swap substitution].

I did a few other things along the way

* Fix a bug in StgCse, which could allow a loop breaker to be CSE'd
  away.  See Note [Care with loop breakers] in StgCse.  I think it can
  only show up if occurrence analyser sets up bad loop breakers, but
  still.

* Better commenting in SimplUtils.prepareAlts

* A little refactoring in CoreUnfold; nothing significant
  e.g. rename CoreUnfold.mkTopUnfolding to mkFinalUnfolding

* Renamed CoreSyn.isFragileUnfolding to hasCoreUnfolding

* Move mkRuleInfo to CoreFVs

We observed respectively 4.6% and 5.9% allocation decreases for the following
tests:

Metric Decrease:
    T9961
    haddock.base

- - - - -
0e46a528 by Sebastian Graf at 2020-04-01T15:35:26-04:00
Preserve precise exceptions in strictness analysis

Fix #13380 and #17676 by

1. Changing `raiseIO#` to have `topDiv` instead of `botDiv`
2. Give it special treatment in `Simplifier.Util.mkArgInfo`, treating it
   as if it still had `botDiv`, to recover dead code elimination.

This is the first commit of the plan outlined in
https://gitlab.haskell.org/ghc/ghc/-/merge_requests/2525#note_260886.

- - - - -
30b3a1f5 by Ömer Sinan Ağacan at 2020-04-01T15:35:34-04:00
Fix a pointer format string in RTS

- - - - -
aa0b14e8 by Ömer Sinan Ağacan at 2020-04-01T15:35:36-04:00
Remove unused closure stg_IND_direct

- - - - -
56d1e9b5 by Ben Gamari at 2020-04-01T15:35:36-04:00
Session: Memoize stderrSupportsAnsiColors

Not only is this a reasonable efficiency measure but it avoids making
reentrant calls into ncurses, which is not thread-safe. See #17922.

- - - - -
f58d4b8d by Ryan Scott at 2020-04-01T15:35:37-04:00
Make Hadrian build with Cabal-3.2

GHC 8.10 ships with `Cabal-3.2.0.0`, so it would be convenient to
make Hadrian supporting building against 3.2.* instead of having to
rebuild the entirety of `Cabal-3.0.0.0`. There is one API change in
`Cabal-3.2.*` that affects Hadrian: the `synopsis` and `description`
functions now return `ShortText` instead of `String`. Since Hadrian
manipulates these `String`s in various places, I found that the
simplest fix was to use CPP to convert `ShortText` to `String`s
where appropriate.

- - - - -
159ea43f by Sylvain Henry at 2020-04-01T15:35:43-04:00
Update Stack resolver for hadrian/build-stack

Broken by 57b888c0e90be7189285a6b078c30b26d0923809

- - - - -
cf407bed by Ryan Scott at 2020-04-01T15:35:43-04:00
Fix two ASSERT buglets in reifyDataCon

Two `ASSERT`s in `reifyDataCon` were always using `arg_tys`, but
`arg_tys` is not meaningful for GADT constructors. In fact, it's
worse than non-meaningful, since using `arg_tys` when reifying a
GADT constructor can lead to failed `ASSERT`ions, as #17305
demonstrates.

This patch applies the simplest possible fix to the immediate
problem. The `ASSERT`s now use `r_arg_tys` instead of `arg_tys`, as
the former makes sure to give something meaningful for GADT
constructors. This makes the panic go away at the very least. There
is still an underlying issue with the way the internals of
`reifyDataCon` work, as described in
https://gitlab.haskell.org/ghc/ghc/issues/17305#note_227023, but we
leave that as future work, since fixing the underlying issue is
much trickier (see
https://gitlab.haskell.org/ghc/ghc/issues/17305#note_227087).

- - - - -

30 changed files:

- compiler/GHC/Core.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/Op/OccurAnal.hs
- compiler/GHC/Core/Op/Simplify.hs
- compiler/GHC/Core/Op/Simplify/Utils.hs
- compiler/GHC/Core/Rules.hs
- compiler/GHC/Core/Subst.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/CoreToStg/Prep.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/HsToCore/PmCheck/Oracle.hs
- compiler/GHC/Iface/Tidy.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Stg/CSE.hs
- compiler/GHC/Types/Demand.hs
- compiler/GHC/Types/Id/Info.hs
- compiler/GHC/Types/Id/Make.hs
- compiler/main/SysTools/Terminal.hs
- compiler/prelude/primops.txt.pp
- compiler/typecheck/TcSplice.hs
- hadrian/hadrian.cabal
- hadrian/src/Hadrian/Haskell/Cabal/Parse.hs
- hadrian/src/Rules/Library.hs
- hadrian/src/Settings/Builders/Ghc.hs
- hadrian/stack.yaml
- includes/stg/MiscClosures.h
- rts/StgMiscClosures.cmm
- rts/sm/GC.c
- testsuite/tests/dependent/should_compile/dynamic-paper.stderr

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/ecdc6599d4aacbc8593ef4b415b8bac7dbc789c0...cf407bed46880760bb35be268651434775c0036c

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/ecdc6599d4aacbc8593ef4b415b8bac7dbc789c0...cf407bed46880760bb35be268651434775c0036c
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/20200401/8be03612/attachment-0001.html>