[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 13 commits: Refactor hole constraints.

Marge Bot gitlab at gitlab.haskell.org
Wed May 6 11:46:41 UTC 2020 


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


Commits:
7ab6ab09 by Richard Eisenberg at 2020-05-06T04:39:32-04:00
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
-------------------------

- - - - -
420b957d by Ben Gamari at 2020-05-06T04:40:08-04:00
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.

- - - - -
740b3b8d by Ben Gamari at 2020-05-06T04:40:08-04:00
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.

- - - - -
b2d72c75 by Ben Gamari at 2020-05-06T04:40:08-04:00
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.

- - - - -
9f3e6884 by Zubin Duggal at 2020-05-06T04:41:08-04:00
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

- - - - -
edec6a6c by Ryan Scott at 2020-05-06T04:41:57-04:00
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.

- - - - -
a95e7fe0 by Ömer Sinan Ağacan at 2020-05-06T04:42:39-04:00
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;

- - - - -
cab1871a by Sylvain Henry at 2020-05-06T04:43:21-04:00
Move LeadingUnderscore into Platform (#17957)

Avoid direct use of DynFlags to know if symbols must be prefixed by an
underscore.

- - - - -
94e7c563 by Sylvain Henry at 2020-05-06T04:43:21-04:00
Don't use DynFlags in showLinkerState (#17957)

- - - - -
9afd9251 by Ryan Scott at 2020-05-06T04:43:58-04:00
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.

- - - - -
4986853e by Adam Gundry at 2020-05-06T07:46:35-04:00
Reject all duplicate declarations involving DuplicateRecordFields (fixes #17965)

This fixes a bug that resulted in some programs being accepted that used the same
identifier as a field label and another declaration, depending on the order they
appeared in the source code.

- - - - -
67ffeb3a by Simon Peyton Jones at 2020-05-06T07:46:36-04:00
Fix specialisation for DFuns

When specialising a DFun we must take care to saturate the
unfolding.  See Note [Specialising DFuns] in Specialise.

Fixes #18120

- - - - -
6aeb9888 by Ryan Scott at 2020-05-06T07:46:36-04:00
Bump exceptions submodule so that dist-boot is .gitignore'd

`exceptions` is a stage-0 boot library as of commit
30272412fa437ab8e7a8035db94a278e10513413, which means that building
`exceptions` in a GHC tree will generate a `dist-boot` directory.
However, this directory was not specified in `exceptions`'
`.gitignore` file, which causes it to dirty up the current `git`
working directory.

Accordingly, this bumps the `exceptions` submodule to commit
ghc/packages/exceptions at 23c0b8a50d7592af37ca09beeec16b93080df98f,
which adds `dist-boot` to the `.gitignore` file.

- - - - -


30 changed files:

- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Core/Opt/Specialise.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/HsToCore/Binds.hs
- compiler/GHC/HsToCore/PmCheck/Oracle.hs
- compiler/GHC/Iface/Ext/Binary.hs
- compiler/GHC/Plugins.hs
- compiler/GHC/Rename/Bind.hs
- compiler/GHC/Rename/Names.hs
- compiler/GHC/Runtime/Linker.hs
- compiler/GHC/Settings.hs
- compiler/GHC/Settings/IO.hs
- compiler/GHC/Tc/Errors.hs
- compiler/GHC/Tc/Errors/Hole.hs
- compiler/GHC/Tc/Errors/Hole.hs-boot
- compiler/GHC/Tc/Errors/Hole/FitTypes.hs
- compiler/GHC/Tc/Gen/Expr.hs
- compiler/GHC/Tc/Gen/HsType.hs
- compiler/GHC/Tc/Gen/Rule.hs
- compiler/GHC/Tc/Gen/Sig.hs
- compiler/GHC/Tc/Module.hs
- compiler/GHC/Tc/Solver.hs
- compiler/GHC/Tc/Solver/Canonical.hs
- compiler/GHC/Tc/Solver/Flatten.hs
- compiler/GHC/Tc/Solver/Interact.hs
- compiler/GHC/Tc/Solver/Monad.hs
- compiler/GHC/Tc/Types/Constraint.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d3cc9c8ed9a3910febec4c25ed915ea7de7ad0f3...6aeb9888fc1f3cb5ca2033642edf40852e911c18

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d3cc9c8ed9a3910febec4c25ed915ea7de7ad0f3...6aeb9888fc1f3cb5ca2033642edf40852e911c18
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/20200506/ee0e5449/attachment.html>

More information about the ghc-commits mailing list