<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html lang="en">
<head>
<meta content="text/html; charset=US-ASCII" http-equiv="Content-Type">
<title>
GitLab
</title>
<style>img {
max-width: 100%; height: auto;
}
</style>
</head>
<body>
<div class="content">
<h3>
Marge Bot pushed to branch wip/marge_bot_batch_merge_job
at <a href="https://gitlab.haskell.org/ghc/ghc">Glasgow Haskell Compiler / GHC</a>
</h3>
<h4>
Commits:
</h4>
<ul>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/b8a34b8119d9a587dbf64f7b149fb9478edf5225">b8a34b81</a></strong>
<div>
<span>by Richard Eisenberg</span>
<i>at 2020-05-05T21:48:54-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Refactor hole constraints.
Previously, holes (both expression holes / out of scope variables and
partial-type-signature wildcards) were emitted as *constraints* via
the CHoleCan constructor. While this worked fine for error reporting,
there was a fair amount of faff in keeping these constraints in line.
In particular, and unlike other constraints, we could never change
a CHoleCan to become CNonCanonical. In addition:
* the "predicate" of a CHoleCan constraint was really the type
of the hole, which is not a predicate at all
* type-level holes (partial type signature wildcards) carried
evidence, which was never used
* tcNormalise (used in the pattern-match checker) had to create
a hole constraint just to extract it again; it was quite messy
The new approach is to record holes directly in WantedConstraints.
It flows much more nicely now.
Along the way, I did some cleaning up of commentary in
GHC.Tc.Errors.Hole, which I had a hard time understanding.
This was instigated by a future patch that will refactor
the way predicates are handled. The fact that CHoleCan's
"predicate" wasn't really a predicate is incompatible with
that future patch.
No test case, because this is meant to be purely internal.
It turns out that this change improves the performance of
the pattern-match checker, likely because fewer constraints
are sloshing about in tcNormalise. I have not investigated
deeply, but an improvement is not a surprise here:
-------------------------
Metric Decrease:
PmSeriesG
-------------------------
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/12425b89969f8642cf150d652c791718ca09485d">12425b89</a></strong>
<div>
<span>by Ben Gamari</span>
<i>at 2020-05-05T21:48:54-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">rts: Zero block flags with -DZ
Block flags are very useful for determining the state of a block.
However, some block allocator users don't touch them, leading to
misleading values. Ensure that we zero then when zero-on-gc is set. This
is safe and makes the flags more useful during debugging.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/7f3f62a8e78a458c5e19163bf19a6c432bb5de48">7f3f62a8</a></strong>
<div>
<span>by Ben Gamari</span>
<i>at 2020-05-05T21:48:54-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">nonmoving: Fix incorrect failed_to_evac value during deadlock gc
Previously we would incorrectly set the failed_to_evac flag if we
evacuated a value due to a deadlock GC. This would cause us to mark more
things as dirty than strictly necessary. It also turned up a nasty but
which I will fix next.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/6e203bd493ab7a166677e23ea55ceb489935d400">6e203bd4</a></strong>
<div>
<span>by Ben Gamari</span>
<i>at 2020-05-05T21:48:54-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">nonmoving: Fix handling of dirty objects
Previously we (incorrectly) relied on failed_to_evac to be "precise".
That is, we expected it to only be true if *all* of an object's fields
lived outside of the non-moving heap. However, does not match the
behavior of failed_to_evac, which is true if *any* of the object's
fields weren't promoted (meaning that some others *may* live in the
non-moving heap).
This is problematic as we skip the non-moving write barrier for dirty
objects (which we can only safely do if *all* fields point outside of
the non-moving heap).
Clearly this arises due to a fundamental difference in the behavior
expected of failed_to_evac in the moving and non-moving collector.
e.g., in the moving collector it is always safe to conservatively say
failed_to_evac=true whereas in the non-moving collector the safe value
is false.
This issue went unnoticed as I never wrote down the dirtiness
invariant enforced by the non-moving collector. We now define this
invariant as
An object being marked as dirty implies that all of its fields are
on the mark queue (or, equivalently, update remembered set).
To maintain this invariant we teach nonmovingScavengeOne to push the
fields of objects which we fail to evacuate to the update remembered
set. This is a simple and reasonably cheap solution and avoids the
complexity and fragility that other, more strict alternative invariants
would require.
All of this is described in a new Note, Note [Dirty flags in the
non-moving collector] in NonMoving.c.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/5887c763273b094c0cf2b5c5ab609d948e8e9b12">5887c763</a></strong>
<div>
<span>by Zubin Duggal</span>
<i>at 2020-05-05T21:48:56-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Allow atomic update of NameCache in readHieFile
The situation arises in ghcide where multiple different threads may need to
update the name cache, therefore with the older interface it could happen
that you start reading a hie file with name cache A and produce name cache
A + B, but another thread in the meantime updated the namecache to A +
C. Therefore if you write the new namecache you will lose the A' updates
from the second thread.
Updates haddock submodule
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/60f3e848aca7f72f30f5784b9b4ec22ef935663b">60f3e848</a></strong>
<div>
<span>by Ryan Scott</span>
<i>at 2020-05-05T21:48:57-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Make isTauTy detect higher-rank contexts
Previously, `isTauTy` would only detect higher-rank `forall`s, not
higher-rank contexts, which led to some minor bugs observed
in #18127. Easily fixed by adding a case for
`(FunTy InvisArg _ _)`.
Fixes #18127.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/d64d96fb3af1f8a0a7a721b7f02ce70e608c3433">d64d96fb</a></strong>
<div>
<span>by Ömer Sinan Ağacan</span>
<i>at 2020-05-05T21:49:09-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">ELF linker: increment curSymbol after filling in fields of current entry
The bug was introduced in a8b7cef4d45 which added a field to the
`symbols` array elements and then updated this code incorrectly:
- oc->symbols[curSymbol++] = nm;
+ oc->symbols[curSymbol++].name = nm;
+ oc->symbols[curSymbol].addr = symbol->addr;
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/40d7e8689f25f1ee494c85e1fd5fd77184d2fdb7">40d7e868</a></strong>
<div>
<span>by Sylvain Henry</span>
<i>at 2020-05-05T21:49:11-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Move LeadingUnderscore into Platform (#17957)
Avoid direct use of DynFlags to know if symbols must be prefixed by an
underscore.
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/a03d740621684fa231ad155fa2f5711019820a75">a03d7406</a></strong>
<div>
<span>by Sylvain Henry</span>
<i>at 2020-05-05T21:49:11-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Don't use DynFlags in showLinkerState (#17957)
</pre>
</li>
<li>
<strong><a href="https://gitlab.haskell.org/ghc/ghc/-/commit/d3cc9c8ed9a3910febec4c25ed915ea7de7ad0f3">d3cc9c8e</a></strong>
<div>
<span>by Ryan Scott</span>
<i>at 2020-05-05T21:49:12-04:00</i>
</div>
<pre class="commit-message" style="white-space: pre-wrap; margin: 0;">Refactoring: Use bindSigTyVarsFV in rnMethodBinds
`rnMethodBinds` was explicitly using `xoptM` to determine if
`ScopedTypeVariables` is enabled before bringing type variables
bound by the class/instance header into scope. However, this `xoptM`
logic is already performed by the `bindSigTyVarsFV` function. This
patch uses `bindSigTyVarsFV` in `rnMethodBinds` to reduce the number
of places where we need to consult if `ScopedTypeVariables` is on.
This is purely refactoring, and there should be no user-visible
change in behavior.
</pre>
</li>
</ul>
<h4>30 changed files:</h4>
<ul>
<li class="file-stats">
<a href="#db697f6aea9f93f1583f1d5c62d25570a1e07f73">
compiler/GHC/Cmm/CLabel.hs
</a>
</li>
<li class="file-stats">
<a href="#84c9d3ba34173297e7d7747e02caa2e004b164fc">
compiler/GHC/Core/Type.hs
</a>
</li>
<li class="file-stats">
<a href="#9a679a2680ef6061397f1987091ea9f96ffe095d">
compiler/GHC/Driver/Main.hs
</a>
</li>
<li class="file-stats">
<a href="#774d88050336ef660c7a219fb06c480c2fc639bc">
compiler/GHC/Driver/Session.hs
</a>
</li>
<li class="file-stats">
<a href="#8d8e5922fde8bc19ffa2bc9cae6b6720abb88564">
compiler/GHC/HsToCore/PmCheck/Oracle.hs
</a>
</li>
<li class="file-stats">
<a href="#699117ec0ed92a01cc9116db16477e81cd1e2ff6">
compiler/GHC/Iface/Ext/Binary.hs
</a>
</li>
<li class="file-stats">
<a href="#4a238b7fd965f958b107d110c96d07962d7a83ec">
compiler/GHC/Plugins.hs
</a>
</li>
<li class="file-stats">
<a href="#af762064d779f7308dd415966c974f27d14f9943">
compiler/GHC/Rename/Bind.hs
</a>
</li>
<li class="file-stats">
<a href="#3556223cd3ef45d787321b5290bf33535a361873">
compiler/GHC/Runtime/Linker.hs
</a>
</li>
<li class="file-stats">
<a href="#906f88b2ba5bce224c8a08c72cea531fdb95ca55">
compiler/GHC/Settings.hs
</a>
</li>
<li class="file-stats">
<a href="#6740fa77d6598a0ef908509264d676d65ab31fd1">
compiler/GHC/Settings/IO.hs
</a>
</li>
<li class="file-stats">
<a href="#e4b9d5e9d2de37561bfd06a2c97a5c924a1bab76">
compiler/GHC/Tc/Errors.hs
</a>
</li>
<li class="file-stats">
<a href="#897218b3e24728ae9e5b0329b949493f1ede80fb">
compiler/GHC/Tc/Errors/Hole.hs
</a>
</li>
<li class="file-stats">
<a href="#cf93ddc86e104212f370f013f519e12cc11e1f70">
compiler/GHC/Tc/Errors/Hole.hs-boot
</a>
</li>
<li class="file-stats">
<a href="#62e5fd382d9730853d0cbcec70620f1065b107cf">
compiler/GHC/Tc/Errors/Hole/FitTypes.hs
</a>
</li>
<li class="file-stats">
<a href="#902811828741e6bcd64702935bbb54edbbd070ef">
compiler/GHC/Tc/Gen/Expr.hs
</a>
</li>
<li class="file-stats">
<a href="#9355bef855426caf5f526925edf351b20f9a86c4">
compiler/GHC/Tc/Gen/HsType.hs
</a>
</li>
<li class="file-stats">
<a href="#04338da99bccd89402218ca19c5724762f0fe641">
compiler/GHC/Tc/Gen/Rule.hs
</a>
</li>
<li class="file-stats">
<a href="#e65390fa5a32c453a81a1c9a3e1c4464d155ca4a">
compiler/GHC/Tc/Module.hs
</a>
</li>
<li class="file-stats">
<a href="#54436e21ea530a66a8a71bcc01c836f4740b8f02">
compiler/GHC/Tc/Solver.hs
</a>
</li>
<li class="file-stats">
<a href="#f018e77421f495c6f75733fee4a511cfe57bebe8">
compiler/GHC/Tc/Solver/Canonical.hs
</a>
</li>
<li class="file-stats">
<a href="#81707f1fe21087531cefd70879aa09c2be5c1d22">
compiler/GHC/Tc/Solver/Flatten.hs
</a>
</li>
<li class="file-stats">
<a href="#f639b0b31b7245cb7d34ac190b798f5ec1c7da2e">
compiler/GHC/Tc/Solver/Interact.hs
</a>
</li>
<li class="file-stats">
<a href="#0c6b585a8a21f8340a85ca2cef89c4b1bf5a8953">
compiler/GHC/Tc/Solver/Monad.hs
</a>
</li>
<li class="file-stats">
<a href="#3b6d78a50c8462304f843b952a88e531718dbbd2">
compiler/GHC/Tc/Types/Constraint.hs
</a>
</li>
<li class="file-stats">
<a href="#93bba9b9e0195db135fec54160523a427ea042fd">
compiler/GHC/Tc/Types/Origin.hs
</a>
</li>
<li class="file-stats">
<a href="#c6e4263ee64c68e57b7525127d98243fce38b1ea">
compiler/GHC/Tc/Utils/Monad.hs
</a>
</li>
<li class="file-stats">
<a href="#94c96afe1bb3b771ffbcfeeca34ce43ebbe76ccb">
compiler/GHC/Tc/Utils/TcMType.hs
</a>
</li>
<li class="file-stats">
<a href="#c30f4ac98f08779ad1bd5a02a27802862c1e9521">
ghc/GHCi/UI.hs
</a>
</li>
<li class="file-stats">
<a href="#16d4aae095d0e0435922b23d0affed0fbcec1dba">
libraries/ghc-boot/GHC/Platform.hs
</a>
</li>
</ul>
<h5>The diff was not included because it is too large.</h5>
</div>
<div class="footer" style="margin-top: 10px;">
<p style="font-size: small; color: #777;">
—
<br>
<a href="https://gitlab.haskell.org/ghc/ghc/-/compare/51045526d2373e5e1bcfcc6d626ceaeb0bc6711d...d3cc9c8ed9a3910febec4c25ed915ea7de7ad0f3">View it on GitLab</a>.
<br>
You're receiving this email because of your account on gitlab.haskell.org.
If you'd like to receive fewer emails, you can
adjust your notification settings.
</p>
</div>
</body>
</html>