[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 9 commits: Remove references to -package-key

Marge Bot gitlab at gitlab.haskell.org
Tue May 5 07:57:49 UTC 2020 


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


Commits:
1d8f80cd by Sylvain Henry at 2020-05-05T03:22:46-04:00
Remove references to -package-key

* remove references to `-package-key` which has been removed in 2016
  (240ddd7c39536776e955e881d709bbb039b48513)

* remove support for `-this-package-key` which has been deprecated at the
  same time

- - - - -
7bc3a65b by Sylvain Henry at 2020-05-05T03:23:31-04:00
Remove SpecConstrAnnotation (#13681)

This has been deprecated since 2013. Use GHC.Types.SPEC instead.

Make GHC.Exts "not-home" for haddock

Metric Decrease:
   haddock.base

- - - - -
3c862f63 by DenisFrezzato at 2020-05-05T03:24:15-04:00
Fix Haskell98 short description in documentation

- - - - -
2420c555 by Ryan Scott at 2020-05-05T03:24:53-04:00
Add regression tests for #16244, #16245, #16758

Commit e3c374cc5bd7eb49649b9f507f9f7740697e3f70 ended up
fixing quite a few bugs:

* This commit fixes #16244 completely. A regression test has been
  added.
* This commit fixes one program from #16245. (The program in
  https://gitlab.haskell.org/ghc/ghc/issues/16245#note_211369 still
  panics, and the program in
  https://gitlab.haskell.org/ghc/ghc/issues/16245#note_211400 still
  loops infinitely.) A regression test has been added for this
  program.
* This commit fixes #16758. Accordingly, this patch removes the
  `expect_broken` label from the `T16758` test case, moves it from
  `should_compile` to `should_fail` (as it should produce an error
  message), and checks in the expected stderr.

- - - - -
40c71c2c by Sylvain Henry at 2020-05-05T03:25:31-04:00
Fix colorized error messages (#18128)

In b3df9e780fb2f5658412c644849cd0f1e6f50331 I broke colorized messages
by using "dump" style instead of "user" style. This commits fixes it.

- - - - -
e884c7cf by Sebastian Graf at 2020-05-05T03:57:31-04:00
DmdAnal: Improve handling of precise exceptions

This patch does two things: Fix possible unsoundness in what was called
the "IO hack" and implement part 2.1 of the "fixing precise exceptions"
plan in
https://gitlab.haskell.org/ghc/ghc/wikis/fixing-precise-exceptions,
which, in combination with !2956, supersedes !3014 and !2525.

**IO hack**

The "IO hack" (which is a fallback to preserve precise exceptions
semantics and thus soundness, rather than some smart thing that
increases precision) is called `exprMayThrowPreciseException` now.
I came up with two testcases exemplifying possible unsoundness (if
twisted enough) in the old approach:

- `T13380d`: Demonstrating unsoundness of the "IO hack" when resorting
             to manual state token threading and direct use of primops.
             More details below.
- `T13380e`: Demonstrating unsoundness of the "IO hack" when we have
             Nested CPR. Not currently relevant, as we don't have Nested
             CPR yet.

Basically, the IO hack assumed that precise exceptions can only be
thrown from a case scrutinee of type `(# State# RealWorld, _ #)`. I
couldn't come up with a program using the `IO` abstraction that violates
this assumption. But it's easy to do so via manual state token threading
and direct use of primops, see `T13380d`. Also similar code might be
generated by Nested CPR in the (hopefully not too) distant future, see
`T13380e`. Hence, we now have a more careful test in `forcesRealWorld`
that passes `T13380{d,e}` (and will hopefully be robust to Nested CPR).

**Precise exceptions**

In #13380 and #17676 we saw that we didn't preserve precise exception
semantics in demand analysis. We fixed that with minimal changes in
!2956, but that was terribly unprincipled.

That unprincipledness resulted in a loss of precision, which is tracked
by these new test cases:

- `T13380b`: Regression in dead code elimination, because !2956 was too
             syntactic about `raiseIO#`
- `T13380c`: No need to apply the "IO hack" when the IO action may not
             throw a precise exception (and the existing IO hack doesn't
             detect that)

Fixing both issues in !3014 turned out to be too complicated and had
the potential to regress in the future. Hence we decided to only fix
`T13380b` and augment the `Divergence` lattice with a new middle-layer
element, `ExnOrDiv`, which means either `Diverges` (, throws an
imprecise exception) or throws a *precise* exception.

See the wiki page on Step 2.1 for more implementational details:
https://gitlab.haskell.org/ghc/ghc/wikis/fixing-precise-exceptions#dead-code-elimination-for-raiseio-with-isdeadenddiv-introducing-exnordiv-step-21

- - - - -
e353bf7b by Richard Eisenberg at 2020-05-05T03:57: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
-------------------------

- - - - -
3cb104b1 by Zubin Duggal at 2020-05-05T03:57:38-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

- - - - -
5c55d411 by Ryan Scott at 2020-05-05T03:57:38-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.

- - - - -


30 changed files:

- compiler/GHC.hs
- compiler/GHC/Builtin/primops.txt.pp
- compiler/GHC/Core/Arity.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/CallArity.hs
- compiler/GHC/Core/Opt/DmdAnal.hs
- compiler/GHC/Core/Opt/FloatIn.hs
- compiler/GHC/Core/Opt/FloatOut.hs
- compiler/GHC/Core/Opt/LiberateCase.hs
- compiler/GHC/Core/Opt/SetLevels.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/Simplify/Utils.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unfold.hs
- compiler/GHC/Core/Utils.hs
- compiler/GHC/Driver/Finder.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/Iface/Tidy.hs
- compiler/GHC/Plugins.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


The diff was not included because it is too large.


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

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5072198b0ee7606ab8a5b7e6d9f64926ae6fdb7d...5c55d411037e77a4851f472b58438ac75e8528d3
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/fa849334/attachment-0001.html>

More information about the ghc-commits mailing list