[Git][ghc/ghc][wip/angerman/ghc-9.0-runpath-backport] 19 commits: Linear types: fix kind inference when checking datacons

Ben Gamari gitlab at gitlab.haskell.org
Wed Oct 14 17:50:01 UTC 2020



Ben Gamari pushed to branch wip/angerman/ghc-9.0-runpath-backport at Glasgow Haskell Compiler / GHC


Commits:
93df442a by Krzysztof Gogolewski at 2020-09-30T01:05:27+03:00
Linear types: fix kind inference when checking datacons

(cherry picked from b31a3360e2ef12f3ec7eaf66b3600247c1eb36c3)

- - - - -
7c7bd94d by Vladislav Zavialov at 2020-09-30T01:06:07+03:00
New linear types syntax: a %p -> b (#18459)

Implements GHC Proposal #356

Updates the haddock submodule.

(cherry-picked from 5830a12c46e7227c276a8a71213057595ee4fc04)

- - - - -
d5e13ceb by Vladislav Zavialov at 2020-10-02T01:39:25+03:00
Fix pretty-printing of the mult-polymorphic arrow

(cherry-picked from a8018c17747342444c67eeec21a506c89c1110e8)

- - - - -
89a00150 by Sylvain Henry at 2020-10-05T10:32:31+02:00
Bignum: add integerNegate RULE

- - - - -
175d7141 by Sylvain Henry at 2020-10-05T10:32:38+02:00
Bignum: implement integerRecipMod (#18427)

- - - - -
5d414fdc by Sylvain Henry at 2020-10-05T10:32:43+02:00
Bignum: implement integerPowMod (#18427)

Incidentally fix powModInteger which was crashing in integer-gmp for
negative exponents when the modular multiplicative inverse for the base
didn't exist. Now we compute it explicitly with integerRecipMod so that
every backend returns the same result without crashing.

- - - - -
b936c542 by MaxGabriel at 2020-10-12T14:19:41+02:00
Document -Wderiving-typeable

Tracking: #18641
(cherry picked from commit 73d2521688bd1da4b6bd1202e5325a00cb410a44)

- - - - -
c073a4ab by Hécate at 2020-10-12T14:20:47+02:00
Remove the list of loaded modules from the ghci prompt

(cherry picked from commit 086ef01813069fad84cafe81cab37527d41c8568)

- - - - -
aff164bc by Benjamin Maurer at 2020-10-12T14:21:51+02:00
Workaround for #18623: GHC crashes bc. under rlimit for vmem it will reserve
_all_ of it, leaving nothing for, e.g., thread stacks.
Fix will only allocate 2/3rds and check whether remainder is at least large
enough for minimum amount of thread stacks.

(cherry picked from commit 74c797f6b72c4d01f5e0092dfac1461f3f3dd7a2)

- - - - -
44779899 by Krzysztof Gogolewski at 2020-10-12T14:22:35+02:00
Add a flag to indicate that gcc supports -no-pie

Fixes #17919.

(cherry picked from commit e48cab2a57f2342891f985bcb44817e17e985275)

- - - - -
ba446875 by Krzysztof Gogolewski at 2020-10-12T14:23:25+02:00
Fix linear types in TH splices (#18465)

(cherry picked from commit 802b5e6fdd6dfc58396a9dca1903dc5a1d6634ca)

- - - - -
b10154d6 by Icelandjack at 2020-10-12T14:25:47+02:00
Replaced MkT1 with T1 in type signatures.

(cherry picked from commit b81350bb925f8cb309355ee46238dbc11b796faf)

- - - - -
baa55369 by Krzysztof Gogolewski at 2020-10-12T14:26:12+02:00
Linear types: fix quantification in GADTs (#18790)

(cherry picked from commit 22f218b729a751bc5e5965624a716fc542f502a5)

- - - - -
146cff70 by Alan Zimmerman at 2020-10-12T14:27:02+02:00
Preserve as-parsed arrow type for HsUnrestrictedArrow

When linear types are disabled, HsUnrestrictedArrow is treated as
HslinearArrow.

Move this adjustment into the type checking phase, so that the parsed
source accurately represents the source as parsed.

Closes #18791

(cherry picked from commit d6dff830754a97220eacf032c32cd54b18654917)

- - - - -
8c370e11 by Alan Zimmerman at 2020-10-12T14:27:30+02:00
ApiAnnotations : preserve parens in GADTs

A cleanup in 7f418acf61e accidentally discarded some parens in
ConDeclGADT.

Make sure these stay in the AST in a usable format.

Also ensure the AnnLolly does not get lost in a GADT.

(cherry picked from commit 36787bba78ae5acbb857c84b85b8feb7c83e54a5)

- - - - -
15c4eb1f by Krzysztof Gogolewski at 2020-10-12T14:28:15+02:00
Linear types: fix roles in GADTs (#18799)

(cherry picked from commit 8fafb304cacae69f8dbbdcf22ab858a5b28b6818)

- - - - -
a740aa0b by Sylvain Henry at 2020-10-12T15:10:13+02:00
Bignum: match on small Integer/Natural

Previously we only matched on *variables* whose unfoldings were a ConApp
of the form `IS lit#` or `NS lit##`. But we forgot to match on the
ConApp directly... As a consequence, constant folding only worked after
the FloatOut pass which creates bindings for most sub-expressions. With
this patch, matching on bignums works even with -O0 (see bignumMatch
test).

- - - - -
d09e7e41 by Sylvain Henry at 2020-10-12T15:10:30+02:00
Bignum: fix bigNatCompareWord# bug (#18813)

(cherry picked from commit 74ee1237bf243dd7d8b758a53695575c364c3088)

- - - - -
07385545 by Moritz Angermann at 2020-10-14T13:49:56-04:00
[macOS] improved runpath handling

In b592bd98ff25730bbe3c13d6f62a427df8c78e28 we started using
-dead_strip_dylib on macOS when lining dynamic libraries and binaries.
The underlying reason being the Load Command Size Limit in macOS
Sierra (10.14) and later.

GHC will produce @rpath/libHS... dependency entries together with a
corresponding RPATH entry pointing to the location of the libHS...
library. Thus for every library we produce two Load Commands.  One to
specify the dependent library, and one with the path where to find it.
This makes relocating libraries and binaries easier, as we just need to
update the RPATH entry with the install_name_tool. The dynamic linker
will then subsitute each @rpath with the RPATH entries it finds in the
libraries load commands or the environement, when looking up @rpath
relative libraries.

-dead_strip_dylibs intructs the linker to drop unused libraries. This in
turn help us reduce the number of referenced libraries, and subsequently
the size of the load commands.  This however does not remove the RPATH
entries.  Subsequently we can end up (in extreme cases) with only a
single @rpath/libHS... entry, but 100s or more RPATH entries in the Load
Commands.

This patch rectifies this (slighly unorthodox) by passing *no* -rpath
arguments to the linker at link time, but -headerpad 8000.  The
headerpad argument is in hexadecimal and the maxium 32k of the load
command size.  This tells the linker to pad the load command section
enough for us to inject the RPATHs later.  We then proceed to link the
library or binary with -dead_strip_dylibs, and *after* the linking
inspect the library to find the left over (non-dead-stripped)
dependencies (using otool).  We find the corresponding RPATHs for each
@rpath relative dependency, and inject them into the library or binary
using the install_name_tool.  Thus achieving a deadstripped dylib (and
rpaths) build product.

We can not do this in GHC, without starting to reimplement a dynamic
linker as we do not know which symbols and subsequently libraries are
necessary.

Commissioned-by: Mercury Technologies, Inc. (mercury.com)
(cherry picked from commit 89a753308deb2c7ed012e875e220b1d39e1798d8)
Signed-off-by: Moritz Angermann <moritz.angermann at gmail.com>

- - - - -


30 changed files:

- aclocal.m4
- compiler/GHC/Core/DataCon.hs
- compiler/GHC/Core/Multiplicity.hs
- compiler/GHC/Core/Opt/Monad.hs
- compiler/GHC/Core/Opt/Simplify.hs
- compiler/GHC/Core/Opt/Simplify/Env.hs
- compiler/GHC/Core/SimpleOpt.hs
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/Hs/Decls.hs
- compiler/GHC/Hs/Type.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/Annotation.hs
- compiler/GHC/Parser/Lexer.x
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/HsType.hs
- compiler/GHC/Rename/Module.hs
- compiler/GHC/Runtime/Linker.hs
- compiler/GHC/Settings.hs
- compiler/GHC/Settings/IO.hs
- compiler/GHC/SysTools.hs
- compiler/GHC/SysTools/Tasks.hs
- compiler/GHC/Tc/Gen/Splice.hs
- compiler/GHC/Tc/TyCl.hs
- compiler/GHC/Tc/TyCl/Utils.hs
- compiler/GHC/Types/Id/Make.hs
- compiler/GHC/Utils/Outputable.hs
- configure.ac
- docs/users_guide/9.0.1-notes.rst
- docs/users_guide/expected-undocumented-flags.txt


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7895dbef7f903615d212ebcb733812b8e60cc37c...07385545bed6099c7e5b7fd28f0b0a7fa7910fae

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7895dbef7f903615d212ebcb733812b8e60cc37c...07385545bed6099c7e5b7fd28f0b0a7fa7910fae
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/20201014/4b92f6e0/attachment-0001.html>


More information about the ghc-commits mailing list