[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 11 commits: rts: fix top handler closure type signatures

Tue Mar 4 07:21:09 UTC 2025

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC

Commits:
c78d8f55 by Cheng Shao at 2025-03-03T20:54:41+00:00
rts: fix top handler closure type signatures

This commit fixes the runIO/runNonIO closure type signatures in the
RTS which should be extern StgClosure. This allows us to remove an
unnecessary type cast in the C foreign desugaring logic, as well as
unneeded complications of JSFFI desugaring logic that also needs to
generate C stubs that may refer to those top handler closures.
Otherwise, we'll have to take special care to avoid generating "extern
StgClosure" declarations for them as we would for other closures, just
to avoid conflicting type signature error at stub compile time.

- - - - -
a204df3a by Cheng Shao at 2025-03-03T20:54:41+00:00
compiler: allow arbitrary label string for JSFFI exports

This commit allows arbitrary label string to appear in a foreign
export declaration, as long as the calling convention is javascript.
Well, doesn't make sense to enforce it's a C function symbol for a
JSFFI declaration anyway, and it gets in the way of implementing the
"sync" flavour of exports.

- - - - -
03ebab52 by Cheng Shao at 2025-03-03T20:54:41+00:00
compiler: wasm backend JSFFI sync exports

This commit implements the synchronous flavour of the wasm backend
JSFFI exports:

- `foreign export javascript "foo sync"` exports a top-level Haskell
  binding as a synchronous JS function
- `foreign import javascript "wrapper sync"` dynamically exports a
  Haskell function closure as a synchronous JS function
- `foreign import javascript unsafe` is now re-entrant by lowering to
  a safe ccall
- Also fix the issue that JSFFI dynamic exports didn't really work in
  TH & ghci (#25473)

- - - - -
b6ae908b by Cheng Shao at 2025-03-03T20:54:41+00:00
testsuite: test wasm backend JSFFI sync exports

This commit repurposes some existing JSFFI test cases to make them
cover JSFFI sync exports as well.

- - - - -
edae2874 by Cheng Shao at 2025-03-03T20:54:41+00:00
docs: document wasm backend JSFFI sync exports

This commit updates wasm backend documentation to reflect the new
JSFFI sync exports feature.

- - - - -
9b54eecb by Cheng Shao at 2025-03-03T20:56:21+00:00
wasm: add error message to WouldBlockException

This commit attaches an error message to WouldBlockException, for now
the error message consists of the JS async import code snippet that
thunk is trying to block for. This is useful for debugging synchronous
callbacks that accidentally call an async JS function.

- - - - -
156a8c52 by Cheng Shao at 2025-03-04T02:20:55-05:00
compiler: avoid overwriting existing writers in putWithTables

This patch makes `putWithTables` avoid overwriting all existing
UserData writers in the handle. This is crucial for GHC API users that
use putWithUserData/getWithUserData for serialization logic that
involve Names.

- - - - -
b9c67842 by Matthew Pickering at 2025-03-04T02:20:56-05:00
ghci: Serialise mi_top_env

When loading core from interface files (or from a bytecode object in
future) it's important to store what the top-level context of a module
is.
Otherwise, when you load the module into GHCi from the interface files,
only exported identifiers from the top-level module are in scope on the
repl.

See the added test which demonstrates what this enables.

The context at the GHCi prompt is everything that's in-scope in the
TopEnvIface module. Since TopEnvIface imports identifier "a", we can
evaluate "a" in the repl.

In addition to all this, we can use this information in order to
implement reifyModule in a more principled manner.

This becomes even more important when you're debugging and what to set
break-points on functions which are not imported.

- - - - -
e5baf396 by Matthew Pickering at 2025-03-04T02:20:56-05:00
Implement reifyModule in terms of mi_top_env

mi_top_env provides precisely the information that reifyModule needs,
the user written imports.

This is important as it unblocks !9604 and #22188

Fixes #8489

- - - - -
113952cd by Ben Gamari at 2025-03-04T02:20:56-05:00
hadrian: Refactor handling of test suite environment

Previously we would set the environment variables used to run the
testsuite driver using `setEnv` to set them in the Hadrian process.
While looking into failures of a fix to #25752 I noticed this and took
the opportunity to refactor.

- - - - -
83c1e2ee by Alan Zimmerman at 2025-03-04T02:20:57-05:00
[EPA] Sync with the ghc-exactprint repo

This brings it into line with the changes in
https://hackage.haskell.org/package/ghc-exactprint-1.12.0.0

But also keeps the latest changes from master.

- - - - -

36 changed files:

- compiler/GHC/HsToCore/Foreign/C.hs
- compiler/GHC/HsToCore/Foreign/Wasm.hs
- compiler/GHC/Iface/Binary.hs
- compiler/GHC/Iface/Make.hs
- compiler/GHC/Iface/Syntax.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Rename/Env.hs
- compiler/GHC/Rename/Names.hs
- compiler/GHC/Runtime/Eval.hs
- compiler/GHC/Tc/Gen/Foreign.hs
- compiler/GHC/Tc/Gen/Splice.hs
- compiler/GHC/Tc/Types.hs
- compiler/GHC/Types/Avail.hs
- compiler/GHC/Types/Name/Reader.hs
- compiler/GHC/Types/PkgQual.hs
- compiler/GHC/Unit/Module/ModIface.hs
- docs/users_guide/wasm.rst
- hadrian/src/Rules/Test.hs
- libraries/ghc-internal/src/GHC/Internal/Wasm/Prim/Imports.hs
- libraries/ghc-internal/src/GHC/Internal/Wasm/Prim/Types.hs
- rts/include/RtsAPI.h
- testsuite/tests/ghci/should_run/Makefile
- + testsuite/tests/ghci/should_run/TopEnvIface.hs
- + testsuite/tests/ghci/should_run/TopEnvIface.stdout
- + testsuite/tests/ghci/should_run/TopEnvIface2.hs
- testsuite/tests/ghci/should_run/all.T
- testsuite/tests/jsffi/jsffigc.hs
- testsuite/tests/jsffi/jsffigc.mjs
- testsuite/tests/jsffi/jsffisleep.hs
- testsuite/tests/jsffi/jsffisleep.stdout
- testsuite/tests/jsffi/textconv.hs
- testsuite/tests/jsffi/textconv.mjs
- utils/check-exact/ExactPrint.hs
- utils/check-exact/Main.hs
- utils/check-exact/Transform.hs
- utils/check-exact/Utils.hs

The diff was not included because it is too large.

View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6e0710bcbccb97b2555c6664bcfaed9aeac636a0...83c1e2eed937b2daaddb0803e14b6f44823e117a

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6e0710bcbccb97b2555c6664bcfaed9aeac636a0...83c1e2eed937b2daaddb0803e14b6f44823e117a
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/20250304/3b41e9af/attachment.html>