[Git][ghc/ghc][wip/angerman/aarch64-always-pic] 11 commits: testsuite: Add --top flag to driver
Moritz Angermann
gitlab at gitlab.haskell.org
Tue Nov 3 06:38:46 UTC 2020
Moritz Angermann pushed to branch wip/angerman/aarch64-always-pic at Glasgow Haskell Compiler / GHC
Commits:
4ce2f7d6 by GHC GitLab CI at 2020-11-02T23:45:06-05:00
testsuite: Add --top flag to driver
This allows us to make `config.top` a proper Path. Previously it was a
str, which caused the Ghostscript detection logic to break.
- - - - -
0b772221 by Ben Gamari at 2020-11-02T23:45:42-05:00
Document that ccall convention doesn't support varargs
We do not support foreign "C" imports of varargs functions. While this
works on amd64, in general the platform's calling convention may need
more type information that our Cmm representation can currently provide.
For instance, this is the case with Darwin's AArch64 calling convention.
Document this fact in the users guide and fix T5423 which makes use of a
disallowed foreign import.
Closes #18854.
- - - - -
81006a06 by David Eichmann at 2020-11-02T23:46:19-05:00
RtsAPI: pause and resume the RTS
The `rts_pause` and `rts_resume` functions have been added to `RtsAPI.h` and
allow an external process to completely pause and resume the RTS.
Co-authored-by: Sven Tennie <sven.tennie at gmail.com>
Co-authored-by: Matthew Pickering <matthewtpickering at gmail.com>
Co-authored-by: Ben Gamari <bgamari.foss at gmail.com>
- - - - -
bfb1e272 by Ryan Scott at 2020-11-02T23:46:55-05:00
Display results of GHC.Core.Lint.lint* functions consistently
Previously, the functions in `GHC.Core.Lint` used a patchwork of
different ways to display Core Lint errors:
* `lintPassResult` (which is the source of most Core Lint errors) renders
Core Lint errors with a distinctive banner (e.g.,
`*** Core Lint errors : in result of ... ***`) that sets them apart
from ordinary GHC error messages.
* `lintAxioms`, in contrast, uses a completely different code path that
displays Core Lint errors in a rather confusing manner. For example,
the program in #18770 would give these results:
```
Bug.hs:1:1: error:
Bug.hs:12:1: warning:
Non-*-like kind when *-like expected: RuntimeRep
when checking the body of forall: 'TupleRep '[r]
In the coercion axiom Bug.N:T :: []. Bug.T ~_R Any
Substitution: [TCvSubst
In scope: InScope {r}
Type env: [axl :-> r]
Co env: []]
|
1 | {-# LANGUAGE DataKinds #-}
| ^
```
* Further digging reveals that `GHC.IfaceToCore` displays Core Lint
errors for iface unfoldings as though they were a GHC panic. See, for
example, this excerpt from #17723:
```
ghc: panic! (the 'impossible' happened)
(GHC version 8.8.2 for x86_64-unknown-linux):
Iface Lint failure
In interface for Lib
...
```
This patch makes all of these code paths display Core Lint errors and
warnings consistently. I decided to adopt the conventions that
`lintPassResult` currently uses, as they appear to have been around the
longest (and look the best, in my subjective opinion). We now use the
`displayLintResult` function for all three scenarios mentioned above.
For example, here is what the Core Lint error for the program in #18770 looks
like after this patch:
```
[1 of 1] Compiling Bug ( Bug.hs, Bug.o )
*** Core Lint errors : in result of TcGblEnv axioms ***
Bug.hs:12:1: warning:
Non-*-like kind when *-like expected: RuntimeRep
when checking the body of forall: 'TupleRep '[r_axn]
In the coercion axiom N:T :: []. T ~_R Any
Substitution: [TCvSubst
In scope: InScope {r_axn}
Type env: [axn :-> r_axn]
Co env: []]
*** Offending Program ***
axiom N:T :: T = Any -- Defined at Bug.hs:12:1
*** End of Offense ***
<no location info>: error:
Compilation had errors
```
Fixes #18770.
- - - - -
a9e5f52c by Simon Peyton Jones at 2020-11-02T23:47:31-05:00
Expand type synonyms with :kind!
The User's Guide claims that `:kind!` should expand type synonyms,
but GHCi wasn't doing this in practice. Let's just update the implementation
to match the specification in the User's Guide.
Fixes #13795. Fixes #18828.
Co-authored-by: Ryan Scott <ryan.gl.scott at gmail.com>
- - - - -
1370eda7 by Ben Gamari at 2020-11-02T23:48:06-05:00
hadrian: Don't capture RunTest output
There are a few reasons why capturing the output of the RunTest builder
is undesirable:
* there is a large amount of output which then gets unnecessarily
duplicated by Hadrian if the builder fails
* the output may contain codepoints which are unrepresentable in the
current codepage on Windows, causing Hadrian to crash
* capturing the output causes the testsuite driver to disable
its colorisation logic, making the output less legible.
- - - - -
45af76cd by Moritz Angermann at 2020-11-03T06:31:57+00:00
[AArch64] Aarch64 Always PIC
- - - - -
4ba1c796 by Moritz Angermann at 2020-11-03T06:31:57+00:00
Fix spelling
- - - - -
7f94591b by Moritz Angermann at 2020-11-03T06:31:57+00:00
Drop mmap_next (not needed with forced PIC anymore)
- - - - -
0326390a by Moritz Angermann at 2020-11-03T06:31:57+00:00
Meh, AArch64 is ARM64 in master.
- - - - -
50e81b8d by Moritz Angermann at 2020-11-03T06:31:57+00:00
Fix libdw with -Werror
- - - - -
30 changed files:
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Driver/Main.hs
- compiler/GHC/Driver/Session.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Tc/Module.hs
- compiler/GHC/Tc/Types.hs
- docs/users_guide/9.2.1-notes.rst
- docs/users_guide/exts/ffi.rst
- hadrian/src/Builder.hs
- hadrian/src/Settings/Builders/RunTest.hs
- includes/RtsAPI.h
- includes/rts/Flags.h
- includes/rts/Threads.h
- rts/Capability.c
- rts/Libdw.c
- rts/Linker.c
- rts/LinkerInternals.h
- rts/RtsAPI.c
- rts/Schedule.c
- rts/Task.c
- rts/Task.h
- rts/sm/NonMoving.c
- testsuite/driver/runtests.py
- testsuite/driver/testglobals.py
- testsuite/driver/testlib.py
- testsuite/mk/test.mk
- testsuite/tests/callarity/unittest/CallArity1.hs
- + testsuite/tests/ghci/scripts/T13795.script
- + testsuite/tests/ghci/scripts/T13795.stdout
- + testsuite/tests/ghci/scripts/T18828.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7d441e1849a3be17265cbd1a1db5a4085e4c63ef...50e81b8d20e9aac634760f03bd7e9dbdb0293fb0
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/7d441e1849a3be17265cbd1a1db5a4085e4c63ef...50e81b8d20e9aac634760f03bd7e9dbdb0293fb0
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/20201103/2cdb0a96/attachment-0001.html>
More information about the ghc-commits
mailing list