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

Tue May 5 18:18:33 UTC 2020

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

Commits:
27145d04 by Richard Eisenberg at 2020-05-05T14:18:24-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
-------------------------

- - - - -
7ddb29e0 by Zubin Duggal at 2020-05-05T14:18:25-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

- - - - -
215f7fc1 by Ryan Scott at 2020-05-05T14:18:25-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.

- - - - -
d69b6264 by Sylvain Henry at 2020-05-05T14:18:28-04:00
Move LeadingUnderscore into Platform (#17957)

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

- - - - -
9d4e0360 by Sylvain Henry at 2020-05-05T14:18:28-04:00
Don't use DynFlags in showLinkerState (#17957)

- - - - -
51045526 by Ryan Scott at 2020-05-05T14:18:28-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.

- - - - -

30 changed files:

- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/HsToCore/PmCheck/Oracle.hs
- compiler/GHC/Iface/Ext/Binary.hs
- compiler/GHC/Plugins.hs
- compiler/GHC/Rename/Bind.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/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
- compiler/GHC/Tc/Types/Origin.hs
- compiler/GHC/Tc/Utils/Monad.hs
- compiler/GHC/Tc/Utils/TcMType.hs
- ghc/GHCi/UI.hs
- libraries/ghc-boot/GHC/Platform.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5c55d411037e77a4851f472b58438ac75e8528d3...51045526d2373e5e1bcfcc6d626ceaeb0bc6711d

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5c55d411037e77a4851f472b58438ac75e8528d3...51045526d2373e5e1bcfcc6d626ceaeb0bc6711d
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/20200505/0030e8d5/attachment-0001.html>