[Git][ghc/ghc][wip/T8095-spj] 38 commits: hadrian: Fix running stage0/bin/ghc with wrong package DB. Fixes #17468.

Simon Peyton Jones gitlab at gitlab.haskell.org
Tue Aug 11 10:36:27 UTC 2020



Simon Peyton Jones pushed to branch wip/T8095-spj at Glasgow Haskell Compiler / GHC


Commits:
947206f4 by Niklas Hambüchen at 2020-08-03T07:52:33+02:00
hadrian: Fix running stage0/bin/ghc with wrong package DB. Fixes #17468.

In the invocation of `cabal configure`, `--ghc-pkg-option=--global-package-db`
was already given correctly to tell `stage0/bin/ghc-pkg` that it should use
the package DB in `stage1/`.

However, `ghc` needs to be given this information as well, not only `ghc-pkg`!
Until now that was not the case; the package DB in `stage0` was given to
`ghc` instead.
This was wrong, because there is no binary compatibility guarantee that says
that the `stage0` DB's `package.cache` (which is written by the
stage0 == system-provided ghc-pkg) can be deserialised by the `ghc-pkg`
from the source code tree.

As a result, when trying to add fields to `InstalledPackageInfo` that get
serialised into / deserialised from the `package.cache`, errors like

    _build/stage0/lib/package.conf.d/package.cache: GHC.PackageDb.readPackageDb: inappropriate type (Not a valid Unicode code point!)

would appear. This was because the `stage0/bin/ghc would try to
deserialise the newly added fields from
`_build/stage0/lib/package.conf.d/package.cache`, but they were not in there
because the system `ghc-pkg` doesn't know about them and thus didn't write them
there.
It would try to do that because any GHC by default tries to read the global
package db in `../lib/package.conf.d/package.cache`.
For `stage0/bin/ghc` that *can never work* as explained above, so we
must disable this default via `-no-global-package-db` and give it the
correct package DB explicitly.

This is the same problem as #16534, and the same fix as in MR !780
(but in another context; that one was for developers trying out the
`stage0/bin/ghc` == `_build/ghc-stage1` interactively, while this fix
is for a `cabal configure` invocation).

I also noticed that the fix for #16534 forgot to pass `-no-global-package-db`,
and have fixed that in this commit as well.
It only worked until now because nobody tried to add a new ghc-pkg `.conf`
field since the introduction of Hadrian.

- - - - -
ef2ae81a by Alex Biehl at 2020-08-03T07:52:33+02:00
Hardcode RTS includes to cope with unregistered builds

- - - - -
d613ed76 by Sylvain Henry at 2020-08-05T03:59:27-04:00
Bignum: add backward compat integer-gmp functions

Also enhance bigNatCheck# and isValidNatural test

- - - - -
3f2f7718 by Sylvain Henry at 2020-08-05T03:59:27-04:00
Bignum: add more BigNat compat functions in integer-gmp

- - - - -
5e12cd17 by Krzysztof Gogolewski at 2020-08-05T04:00:04-04:00
Rename Core.Opt.Driver -> Core.Opt.Pipeline

Closes #18504.

- - - - -
2bff2f87 by Ben Gamari at 2020-08-05T04:00:39-04:00
Revert "iserv: Don't pass --export-dynamic on FreeBSD"

This reverts commit 2290eb02cf95e9cfffcb15fc9c593d5ef79c75d9.

- - - - -
53ce0db5 by Ben Gamari at 2020-08-05T04:00:39-04:00
Refactor handling of object merging

Previously to merge a set of object files we would invoke the linker as
usual, adding -r to the command-line. However, this can result in
non-sensical command-lines which causes lld to balk (#17962).

To avoid this we introduce a new tool setting into GHC, -pgmlm, which is
the linker which we use to merge object files.

- - - - -
eb7013c3 by Hécate at 2020-08-05T04:01:15-04:00
Remove all the unnecessary LANGUAGE pragmas

- - - - -
fbcb886d by Ryan Scott at 2020-08-05T04:01:51-04:00
Make CodeQ and TExpQ levity polymorphic

The patch is quite straightforward. The only tricky part is that
`Language.Haskell.TH.Lib.Internal` now must be `Trustworthy` instead
of `Safe` due to the `GHC.Exts` import (in order to import `TYPE`).

Since `CodeQ` has yet to appear in any released version of
`template-haskell`, I didn't bother mentioning the change to `CodeQ`
in the `template-haskell` release notes.

Fixes #18521.

- - - - -
686e06c5 by Vladislav Zavialov at 2020-08-06T13:34:05-04:00
Grammar for types and data/newtype constructors

Before this patch, we parsed types into a reversed sequence
of operators and operands. For example, (F x y + G a b * X)
would be parsed as [X, *, b, a, G, +, y, x, F],
using a simple grammar:

	tyapps
	  : tyapp
	  | tyapps tyapp

	tyapp
	  : atype
	  | PREFIX_AT atype
	  | tyop
	  | unpackedness

Then we used a hand-written state machine to assemble this
 either into a type,        using 'mergeOps',
     or into a constructor, using 'mergeDataCon'.

This is due to a syntactic ambiguity:

	data T1 a =          MkT1 a
	data T2 a = Ord a => MkT2 a

In T1, what follows after the = sign is a data/newtype constructor
declaration. However, in T2, what follows is a type (of kind
Constraint). We don't know which of the two we are parsing until we
encounter =>, and we cannot check for => without unlimited lookahead.

This poses a few issues when it comes to e.g. infix operators:

	data I1 = Int :+ Bool :+ Char          -- bad
	data I2 = Int :+ Bool :+ Char => MkI2  -- fine

By this issue alone we are forced into parsing into an intermediate
representation and doing a separate validation pass.

However, should that intermediate representation be as low-level as a
flat sequence of operators and operands?

Before GHC Proposal #229, the answer was Yes, due to some particularly
nasty corner cases:

	data T = ! A :+ ! B          -- used to be fine, hard to parse
	data T = ! A :+ ! B => MkT   -- bad

However, now the answer is No, as this corner case is gone:

	data T = ! A :+ ! B          -- bad
	data T = ! A :+ ! B => MkT   -- bad

This means we can write a proper grammar for types, overloading it in
the DisambECP style, see Note [Ambiguous syntactic categories].

With this patch, we introduce a new class, DisambTD. Just like
DisambECP is used to disambiguate between expressions, commands, and patterns,
DisambTD  is used to disambiguate between types and data/newtype constructors.

This way, we get a proper, declarative grammar for constructors and
types:

	infixtype
	  : ftype
	  | ftype tyop infixtype
	  | unpackedness infixtype

	ftype
	  : atype
	  | tyop
	  | ftype tyarg
	  | ftype PREFIX_AT tyarg

	tyarg
	  : atype
	  | unpackedness atype

And having a grammar for types means we are a step closer to using a
single grammar for types and expressions.

- - - - -
6770e199 by Vladislav Zavialov at 2020-08-06T13:34:05-04:00
Clean up the story around runPV/runECP_P/runECP_PV

This patch started as a small documentation change, an attempt to make
Note [Parser-Validator] and Note [Ambiguous syntactic categories]
more clear and up-to-date.

But it turned out that runECP_P/runECP_PV are weakly motivated,
and it's easier to remove them than to find a good rationale/explanation
for their existence.

As the result, there's a bit of refactoring in addition to
a documentation update.

- - - - -
826d07db by Vladislav Zavialov at 2020-08-06T13:34:06-04:00
Fix debug_ppr_ty ForAllTy (#18522)

Before this change, GHC would
pretty-print   forall k. forall a -> ()
          as   forall @k a. ()
which isn't even valid Haskell.

- - - - -
0ddb4384 by Vladislav Zavialov at 2020-08-06T13:34:06-04:00
Fix visible forall in ppr_ty (#18522)

Before this patch, this type:
  T :: forall k -> (k ~ k) => forall j -> k -> j -> Type
was printed incorrectly as:
  T :: forall k j -> (k ~ k) => k -> j -> Type

- - - - -
d2a43225 by Richard Eisenberg at 2020-08-06T13:34:06-04:00
Fail eagerly on a lev-poly datacon arg

Close #18534.

See commentary in the patch.

- - - - -
63348155 by Sylvain Henry at 2020-08-06T13:34:08-04:00
Use a type alias for Ways

- - - - -
9570c212 by Takenobu Tani at 2020-08-06T19:46:46-04:00
users-guide: Rename 8.12 to 9.0

GHC 8.12.1 has been renamed to GHC 9.0.1.

See also:
  https://mail.haskell.org/pipermail/ghc-devs/2020-July/019083.html

[skip ci]

- - - - -
3907ee01 by Cale Gibbard at 2020-08-07T08:34:46-04:00
A fix to an error message in monad comprehensions, and a move of dsHandleMonadicFailure
as suggested by comments on !2330.

- - - - -
fa9bb70a by Cale Gibbard at 2020-08-07T08:34:46-04:00
Add some tests for fail messages in do-expressions and monad-comprehensions.

- - - - -
5f036063 by Ben Gamari at 2020-08-07T08:35:21-04:00
cmm: Clean up Notes a bit

- - - - -
6402c124 by Ben Gamari at 2020-08-07T08:35:21-04:00
CmmLint: Check foreign call argument register invariant

As mentioned in Note [Register parameter passing] the arguments of
foreign calls cannot refer to caller-saved registers.

- - - - -
15b36de0 by Ben Gamari at 2020-08-07T08:35:21-04:00
nativeGen: One approach to fix #18527

Previously the code generator could produce corrupt C call sequences due
to register overlap between MachOp lowerings and the platform's calling
convention. We fix this using a hack described in Note [Evaluate C-call
arguments before placing in destination registers].

- - - - -
3847ae0c by Ben Gamari at 2020-08-07T08:35:21-04:00
testsuite: Add test for #18527

- - - - -
dd51d53b by Ben Gamari at 2020-08-07T08:35:21-04:00
testsuite: Fix prog001

Previously it failed as the `ghc` package was not visible.

- - - - -
e4f1b73a by Alan Zimmerman at 2020-08-07T23:58:10-04:00
ApiAnnotations; tweaks for ghc-exactprint update

Remove unused ApiAnns, add one for linear arrow.

Include API Annotations for trailing comma in export list.

- - - - -
8a665db6 by Ben Gamari at 2020-08-07T23:58:45-04:00
configure: Fix double-negation in ld merge-objects check

We want to only run the check if ld is gold.

Fixes the fix to #17962.
- - - - -
a11c9678 by Adam Sandberg Ericsson at 2020-08-09T11:32:25+02:00
hadrian: depend on boot compiler version #18001

- - - - -
c8873b52 by Alan Zimmerman at 2020-08-09T21:17:54-04:00
Api Annotations : Adjust SrcSpans for prefix bang (!).

And prefix ~

(cherry picked from commit 8dbee2c578b1f642d45561be3f416119863e01eb)

- - - - -
77398b67 by Sylvain Henry at 2020-08-09T21:18:34-04:00
Avoid allocations in `splitAtList` (#18535)

As suspected by @simonpj in #18535, avoiding allocations in
`GHC.Utils.Misc.splitAtList` when there are no leftover arguments is
beneficial for performance:

   On CI validate-x86_64-linux-deb9-hadrian:
    T12227 -7%
    T12545 -12.3%
    T5030  -10%
    T9872a -2%
    T9872b -2.1%
    T9872c -2.5%

Metric Decrease:
    T12227
    T12545
    T5030
    T9872a
    T9872b
    T9872c

- - - - -
8ba41a0f by Felix Yan at 2020-08-10T20:23:29-04:00
Correct a typo in ghc.mk
- - - - -
1c469264 by Felix Yan at 2020-08-10T20:23:29-04:00
Add a closing parenthesis too

- - - - -
acf537f9 by Sylvain Henry at 2020-08-10T20:24:09-04:00
Make splitAtList strict in its arguments

Also fix its slightly wrong comment

Metric Decrease:
    T5030
    T12227
    T12545

- - - - -
170d5f0b by Simon Peyton Jones at 2020-08-11T11:35:54+01:00
Zap coercions (take 2)

This is Simon's take on coercion zapping.

The basic approach remains the same: add a UnivProv for a zapped
coercion, controlled by -ddrop-coercions.  Particular features:

* A zapped coercion is born in one place only: in GHC.Tc.Utils.Zonk,
  when zonking a coercion.  By that time all coercion holes are
  filled in, so there is no issue about looking for free holes.

* Flattening and solving are unaffected. They'll allocate
  coercions -- but my plan (not yet brought to fruition)
  is that they are never traversed when we have -ddrop-coercions

* There will, therefore, be no perf gain in the type checker;
  but the entire rest of the compiler will benefit.

- - - - -
dda74075 by Simon Peyton Jones at 2020-08-11T11:35:54+01:00
CI adjustments

This patch temporarily
* Marks -ddump-coercions as undocumented (so that CI doesn't stumble)
* Adds -ddump-coercions to TEST_HC so that all tests run with it on

- - - - -
67ef75dc by Simon Peyton Jones at 2020-08-11T11:35:54+01:00
Free-var fixes

This should stop the perf regressions

- - - - -
a7ff3a30 by Simon Peyton Jones at 2020-08-11T11:35:54+01:00
Simplify TyCoFolder

This commit removes the 'env' part of TyCoFolder.  A nice
simplification!

- - - - -
229c908f by Simon Peyton Jones at 2020-08-11T11:35:54+01:00
Tidy up and documentation Notes

- - - - -
f255f49b by Simon Peyton Jones at 2020-08-11T11:35:55+01:00
Two perf wibbles

- - - - -
dd4b25f1 by Simon Peyton Jones at 2020-08-11T11:35:55+01:00
Further wibbles

- - - - -


30 changed files:

- aclocal.m4
- compiler/GHC.hs
- compiler/GHC/Cmm/Lint.hs
- compiler/GHC/Cmm/MachOp.hs
- compiler/GHC/Cmm/Node.hs
- compiler/GHC/Cmm/Sink.hs
- compiler/GHC/CmmToAsm/X86/CodeGen.hs
- compiler/GHC/Core/Coercion.hs
- compiler/GHC/Core/Coercion/Opt.hs
- compiler/GHC/Core/FVs.hs
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Core/Opt/Driver.hs → compiler/GHC/Core/Opt/Pipeline.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/TyCo/FVs.hs
- compiler/GHC/Core/TyCo/Ppr.hs
- compiler/GHC/Core/TyCo/Rep.hs
- compiler/GHC/Core/TyCo/Subst.hs
- compiler/GHC/Core/TyCo/Tidy.hs
- compiler/GHC/Core/Type.hs
- compiler/GHC/Core/Unify.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/Driver/CodeOutput.hs
- compiler/GHC/Driver/Flags.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/HsToCore/Expr.hs
- compiler/GHC/HsToCore/Expr.hs-boot
- compiler/GHC/HsToCore/ListComp.hs
- compiler/GHC/HsToCore/Utils.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d35f1fefd24846dee79a6572c6b957309814d3fd...dd4b25f1d6d6b990769098d07b047f70b3fd48a4

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/d35f1fefd24846dee79a6572c6b957309814d3fd...dd4b25f1d6d6b990769098d07b047f70b3fd48a4
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/20200811/8258b107/attachment-0001.html>


More information about the ghc-commits mailing list