[Git][ghc/ghc][wip/ghc-8.8-merges] 24 commits: ErrUtils: Emit progress messages to eventlog

Ben Gamari gitlab at gitlab.haskell.org
Sun Jun 23 17:27:29 UTC 2019 


Ben Gamari pushed to branch wip/ghc-8.8-merges at Glasgow Haskell Compiler / GHC


Commits:
abf568dd by Ben Gamari at 2019-06-16T15:32:08Z
ErrUtils: Emit progress messages to eventlog

(cherry picked from commit 1bef62c38d3737b5f5d7ebbb479f3c1a12b1aa09)

- - - - -
048d4d22 by Ben Gamari at 2019-06-16T15:32:08Z
Emit GHC timing events to eventlog

(cherry picked from commit ebfa35284741fca47719f531f0996261441f75b0)

- - - - -
ce6a492b by Simon Peyton Jones at 2019-06-19T16:39:50Z
Fail fast in solveLocalEqualities

This patch makes us fail fast in TcSimplify.solveLocalEqualities,
and in TcHsType.tc_hs_sig_type, if there are insoluble constraints.

Previously we ploughed on even if there were insoluble constraints,
leading to a cascade of hard-to-understand type errors. Failing
eagerly is much better; hence a lot of testsuite error message
changes.  Eg if we have
          f :: [Maybe] -> blah
          f xs = e
then trying typecheck 'f x = e' with an utterly bogus type
is just asking for trouble.

I can't quite remember what provoked me to make this change,
but I think the error messages are notably improved, by
removing confusing clutter and focusing on the real error.

(cherry picked from commit 5c1f268e2744fab2d36e64c163858995451d7095)

- - - - -
4a5ab8f0 by Richard Eisenberg at 2019-06-19T16:39:50Z
Fix #16517 by bumping the TcLevel for method sigs

There were actually two bugs fixed here:

1. candidateQTyVarsOfType needs to be careful that it does not
   try to zap metavariables from an outer scope as "naughty"
   quantification candidates. This commit adds a simple check
   to avoid doing so.

2. We weren't bumping the TcLevel in kcHsKindSig, which was used
   only for class method sigs. This mistake led to the acceptance
   of

     class C a where
       meth :: forall k. Proxy (a :: k) -> ()

   Note that k is *locally* quantified. This patch fixes the
   problem by using tcClassSigType, which correctly bumps the
   level. It's a bit inefficient because tcClassSigType does other
   work, too, but it would be tedious to repeat much of the code
   there with only a few changes. This version works well and is
   simple.

And, while updating comments, etc., I noticed that tcRnType was
missing a pushTcLevel, leading to #16767, which this patch also
fixes, by bumping the level. In the refactoring here, I also
use solveEqualities. This initially failed ghci/scripts/T15415,
but that was fixed by teaching solveEqualities to respect
-XPartialTypeSignatures.

This patch also cleans up some Notes around error generation that
came up in conversation.

Test case: typecheck/should_fail/T16517, ghci/scripts/T16767

(cherry picked from commit a22e51ea6f7a046c87d57ce30d143eef6abee9ff)
(cherry picked from commit 19ab32c5fb3ebd88927b94acf6b348facc1552a2)

- - - - -
92543601 by Ben Gamari at 2019-06-21T21:17:46Z
Merge branch 'wip/backport-MR951' into wip/ghc-8.8-merges

- - - - -
7c9c129e by Ben Gamari at 2019-06-22T13:01:34Z
testsuite: Fix expected output

- - - - -
856cdb9d by Michael Peyton Jones at 2019-06-23T17:27:12Z
Visibility: handle multiple units with the same name

Fixes #16228. The included test case is adapted from the reproduction in
the issue, and fails without this patch.

------

We compute an initial visilibity mapping for units based on what is
present in the package databases. To seed this, we compute a set of all
the package configs to add visibilities for.

However, this set was keyed off the unit's *package name*. This is
correct, since we compare packages across databases by version. However,
we would only ever consider a single, most-preferable unit from the
database in which it was found.

The effect of this was that only one of the libraries in a Cabal package
would be added to this initial set. This would cause attempts to use
modules from the omitted libraries to fail, claiming that the package
was hidden (even though `ghc-pkg` would correctly show it as visible).

A solution is to do the selection of the most preferable packages
separately, and then be sure to consider exposing all units in the
same package in the same package db. We can do this by picking a
most-preferable unit for each package name, and then considering
exposing all units that are equi-preferable with that unit.

------

Why wasn't this bug apparent to all people trying to use sub-libraries
in Cabal? The answer is that Cabal explicitly passes `-package` and
`-package-id` flags for all the packages it wants to use, rather than
relying on the state of the package database. So this bug only really
affects people who are trying to use package databases produced by Cabal
outside of Cabal itself.

One particular example of this is the way that the
Nixpkgs Haskell infrastructure provides wrapped GHCs: typically these
are equipped with a package database containing all the needed
package dependencies, and the user is not expected to pass
`-package` flags explicitly.

(cherry picked from commit 8a20bfc21da6a47087c8069f92691629eb47951d)

- - - - -
589ad602 by Simon Peyton Jones at 2019-06-23T17:27:12Z
Add a missing update of sc_hole_ty (#16312)

In simplCast I totally failed to keep the sc_hole_ty field of
ApplyToTy (see Note [The hole type in ApplyToTy]) up to date.
When a cast goes by, of course the hole type changes.

Amazingly this has not bitten us before, but #16312 finally
triggered it.  Fortunately the fix is simple.

Fixes #16312.

(cherry picked from commit ef36b10233e46f8462f42531e8e0c1ebe0bcb1eb)

- - - - -
0b1519b3 by Ben Gamari at 2019-06-23T17:27:12Z
users guide: Mention supported LLVM version

- - - - -
0988b193 by Ben Gamari at 2019-06-23T17:27:12Z
ghci: Ensure that system libffi include path is searched

Previously hsc2hs failed when building against a system FFI.

(cherry picked from commit 1abb76ab8e32e7be224631506201d1beec62a5c2)

- - - - -
bdb70d2e by Shayne Fletcher at 2019-06-23T17:27:12Z
Make Extension derive Bounded

(cherry picked from commit 9047f1844d3f332e15f9e04e74891c771388da3d)

- - - - -
04a27889 by Yuriy Syrovetskiy at 2019-06-23T17:27:12Z
Replace git.haskell.org with gitlab.haskell.org (#16196)

(cherry picked from commit 75abaaead796415cf2b5da610f4b3ee75b9d7759)

- - - - -
ab8a4a3a by Iavor Diatchki at 2019-06-23T17:27:12Z
Add a `NOINLINE` pragma on `someNatVal` (#16586)

This fixes #16586, see `Note [NOINLINE someNatVal]` for details.

(cherry picked from commit 59f4cb6fb73ade6f9b0bdc85380dfddba93bf14b)

- - - - -
c1c0ce7a by Ben Gamari at 2019-06-23T17:27:12Z
testsuite: Add test for #16514

(cherry picked from commit 41bf4045c5a85651db8ceb631a1b67edec0c1216)

- - - - -
1c18d3b4 by Zejun Wu at 2019-06-23T17:27:12Z
Pass preprocessor options to C compiler when building foreign C files (#16737)

(cherry picked from commit cfd3e0f1cfd16c8f35cae139d2a871a32eb4d2e1)

- - - - -
70655b73 by Moritz Angermann at 2019-06-23T17:27:12Z
llvm-targets: Add x86_64 android layout

(cherry picked from commit e87b9f8731460a7d8c0b45507be2d83935683d56)

- - - - -
b508386c by Sergei Trofimovich at 2019-06-23T17:27:12Z
powerpc32: fix 64-bit comparison (#16465)

On powerpc32 64-bit comparison code generated dangling
target labels. This caused ghc build failure as:

    $ ./configure --target=powerpc-unknown-linux-gnu && make
    ...
    SCCs aren't in reverse dependent order
    bad blockId n3U

This happened because condIntCode' in PPC codegen generated
label name but did not place the label into `cmp_lo` code block.

The change adds the `cmp_lo` label into the case of negative
comparison.

Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org>
(cherry picked from commit 973077ac63c79988f2d5f25d13b60dce82f9e8dd)

- - - - -
1a39496a by Sergei Trofimovich at 2019-06-23T17:27:12Z
powerpc32: fix stack allocation code generation

When ghc was built for powerpc32 built failed as:

It's a fallout of commit 3f46cffcc2850e68405a1
("PPC NCG: Refactor stack allocation code") where
word size used to be
    II32/II64
and changed to
    II8/panic "no width for given number of bytes"
    widthFromBytes ((platformWordSize platform) `quot` 8)

The change restores initial behaviour by removing extra division.

Signed-off-by: Sergei Trofimovich <slyfox at gentoo.org>
(cherry picked from commit bb2ee86a4cf47eb56d4b8b4a552537449d492f88)

- - - - -
acfc726a by Krzysztof Gogolewski at 2019-06-23T17:27:12Z
Fix missing unboxed tuple RuntimeReps (#16565)

Unboxed tuples and sums take extra RuntimeRep arguments,
which must be manually passed in a few places.
This was not done in deSugar/Check.

This error was hidden because zipping functions in TyCoRep
ignored lists with mismatching length. This is now fixed;
the lengths are now checked by calling zipEqual.

As suggested in #16565, I moved checking for isTyVar and
isCoVar to zipTyEnv and zipCoEnv.

(cherry picked from commit 69b1633104a43d5654e65f2c05fa6b73775936e2)

- - - - -
31b2eacd by Aiken Cairncross at 2019-06-23T17:27:12Z
Fix typo in error message

(cherry picked from commit ca721193fc71c065036deecfb9d4274fbfc6850d)

- - - - -
f7df329a by Phuong Trinh at 2019-06-23T17:27:12Z
Fix #16525: ObjectCode freed wrongly because of lack of info header check

`checkUnload` currently doesn't check the info header of static objects.
Thus, it may free an `ObjectCode` struct wrongly even if there's still a
live static object whose info header lies in a mapped section of that
`ObjectCode`. This fixes the issue by adding an appropriate check.

(cherry picked from commit fc6b23be509e290f8d27775a1c637284a335ed81)

- - - - -
37a47f67 by Ben Gamari at 2019-06-23T17:27:13Z
SafeHaskell: Don't throw -Wsafe warning if module is declared Safe

Fixes #16689.

(cherry picked from commit 29ec33cd3ee390e8006a88d34f5ea0ac236663d0)

- - - - -
27425530 by Ryan Scott at 2019-06-23T17:27:13Z
Synchronize ClsInst.doTyConApp with TcTypeable validity checks (#15862)

Issue #15862 demonstrated examples of type constructors on which
`TcTypeable.tyConIsTypeable` would return `False`, but the `Typeable`
constraint solver in `ClsInst` (in particular, `doTyConApp`) would
try to generate `Typeable` evidence for anyway, resulting in
disaster. This incongruity was caused by the fact that `doTyConApp`
was using a weaker validity check than `tyConIsTypeable` to determine
if a type constructor warrants `Typeable` evidence or not. The
solution, perhaps unsurprisingly, is to use `tyConIsTypeable` in
`doTyConApp` instead.

To avoid import cycles between `ClsInst` and `TcTypeable`, I factored
out `tyConIsTypeable` into its own module, `TcTypeableValidity`.

Fixes #15862.

(cherry picked from commit 25ee60cdae6ddedaf6b4677c6327c0f31c81073a)

- - - - -
c63f166d by Ömer Sinan Ağacan at 2019-06-23T17:27:13Z
Properly trim IdInfos of DFunIds and PatSyns in TidyPgm

Not doing this right caused #16608. We now properly trim IdInfos of
DFunIds and PatSyns.

Some further refactoring done by SPJ.

Two regression tests T16608_1 and T16608_2 added.

Fixes #16608

(cherry picked from commit 9d58554f7b19c52896796e8c3b6de20c154a67b2)

- - - - -


30 changed files:

- HACKING.md
- README.md
- boot
- compiler/basicTypes/PatSyn.hs
- compiler/coreSyn/CoreTidy.hs
- compiler/deSugar/Check.hs
- compiler/ghc.cabal.in
- compiler/main/DriverPipeline.hs
- compiler/main/ErrUtils.hs
- compiler/main/HscMain.hs
- compiler/main/Packages.hs
- compiler/main/TidyPgm.hs
- compiler/nativeGen/PPC/CodeGen.hs
- compiler/nativeGen/PPC/Instr.hs
- compiler/simplCore/Simplify.hs
- compiler/typecheck/ClsInst.hs
- compiler/typecheck/TcCanonical.hs
- compiler/typecheck/TcErrors.hs
- compiler/typecheck/TcHsType.hs
- compiler/typecheck/TcMType.hs
- compiler/typecheck/TcRnDriver.hs
- compiler/typecheck/TcRnTypes.hs
- compiler/typecheck/TcSimplify.hs
- compiler/typecheck/TcTyClsDecls.hs
- compiler/typecheck/TcType.hs
- compiler/typecheck/TcTypeable.hs
- + compiler/typecheck/TcTypeableValidity.hs
- compiler/types/InstEnv.hs
- compiler/types/TyCoRep.hs
- compiler/types/TyCon.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/abf9bab73d9004bac34a1db14759a6ff7e95b5c9...c63f166d2653b59caf1ee696f746b51c93f6a375

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/compare/abf9bab73d9004bac34a1db14759a6ff7e95b5c9...c63f166d2653b59caf1ee696f746b51c93f6a375
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/20190623/e3164f89/attachment-0001.html>

More information about the ghc-commits mailing list