[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 6 commits: testsuite: Add --top flag to driver
Marge Bot
gitlab at gitlab.haskell.org
Mon Nov 2 23:15:07 UTC 2020
Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC
Commits:
8ff95f7e by GHC GitLab CI at 2020-11-02T18:14:57-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.
- - - - -
71110975 by Ben Gamari at 2020-11-02T18:14:58-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.
- - - - -
aa43281e by David Eichmann at 2020-11-02T18:14:58-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>
- - - - -
3889281e by Ryan Scott at 2020-11-02T18:14:59-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.
- - - - -
87d6dfe4 by Simon Peyton Jones at 2020-11-02T18:14:59-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>
- - - - -
2dc83580 by Ben Gamari at 2020-11-02T18:15:00-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.
- - - - -
30 changed files:
- compiler/GHC/Core/Lint.hs
- compiler/GHC/Driver/Main.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/Threads.h
- rts/Capability.c
- 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
- + testsuite/tests/ghci/scripts/T18828.script
- + testsuite/tests/ghci/scripts/T18828.stdout
- testsuite/tests/ghci/scripts/all.T
- testsuite/tests/rts/T5423.hs
- testsuite/tests/rts/T5423.stdout
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/737d467ffc0200dbe173ccd345a16fc3d8e1bac3...2dc835801c5bb0eba9fb8e55874e2cb1876a8f4c
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/737d467ffc0200dbe173ccd345a16fc3d8e1bac3...2dc835801c5bb0eba9fb8e55874e2cb1876a8f4c
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/20201102/a924efdb/attachment.html>
More information about the ghc-commits
mailing list