[Git][ghc/ghc][wip/ww-max-worker-args-old-arity] 20 commits: Don't return a panic in tcNestedSplice

Sebastian Graf gitlab at gitlab.haskell.org
Fri May 8 13:49:26 UTC 2020 


Sebastian Graf pushed to branch wip/ww-max-worker-args-old-arity at Glasgow Haskell Compiler / GHC


Commits:
8bdc03d6 by Simon Peyton Jones at 2020-05-04T01:56:59-04:00
Don't return a panic in tcNestedSplice

In GHC.Tc.Gen.Splice.tcNestedSplice we were returning a
typechecked expression of "panic". That is usually OK, because
the result is discarded.  But it happens that tcApp now looks at
the typechecked expression, trivially, to ask if it is tagToEnum.
So being bottom is bad.

Moreover a debug-trace might print it out.

So better to return a civilised expression, even though it is
usually discarded.

- - - - -
0bf640b1 by Baldur Blöndal at 2020-05-04T01:57:36-04:00
Don't require parentheses around via type (`-XDerivingVia'). Fixes #18130".

- - - - -
30272412 by Artem Pelenitsyn at 2020-05-04T13:19:59-04:00
Remove custom ExceptionMonad class (#18075) (updating haddock submodule accordingly)

- - - - -
b9f7c08f by jneira at 2020-05-04T13:20:37-04:00
Remove unused hs-boot file

- - - - -
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.

- - - - -
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.

- - - - -
3c9530ab by Sebastian Graf at 2020-05-08T15:49:17+02:00
Make WorkWrap.Lib.isWorkerSmallEnough aware of the old arity

We should allow a wrapper with up to 82 parameters when the original
function had 82 parameters to begin with.

I verified that this made no difference on NoFib, but then again
it doesn't use huge records...

Fixes #18122.

- - - - -


30 changed files:

- compiler/GHC.hs
- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/Core/Opt/SpecConstr.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/Rules.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Data/IOEnv.hs
- compiler/GHC/Driver/Finder.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Make.hs
- compiler/GHC/Driver/Monad.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Driver/Types.hs
- compiler/GHC/HsToCore/PmCheck/Oracle.hs
- compiler/GHC/Iface/Ext/Binary.hs
- compiler/GHC/Iface/Recomp.hs
- compiler/GHC/Parser.y
- compiler/GHC/Plugins.hs
- compiler/GHC/Rename/Bind.hs
- compiler/GHC/Runtime/Debugger.hs
- compiler/GHC/Runtime/Eval.hs
- compiler/GHC/Runtime/Interpreter.hs
- compiler/GHC/Runtime/Linker.hs
- compiler/GHC/Settings.hs
- compiler/GHC/Settings/IO.hs
- compiler/GHC/SysTools/FileCleanup.hs
- compiler/GHC/SysTools/Tasks.hs
- compiler/GHC/Tc/Errors.hs
- compiler/GHC/Tc/Errors/Hole.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6127b827dcea1aa2a66e01e11bb29192a851b02c...3c9530ab5e5c7ba07367a1d7486521a28b6f7245

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6127b827dcea1aa2a66e01e11bb29192a851b02c...3c9530ab5e5c7ba07367a1d7486521a28b6f7245
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/20200508/9e891b00/attachment-0001.html>

More information about the ghc-commits mailing list