[Git][ghc/ghc][wip/T24634-oneshot-bytecode] 11 commits: TTG HsCmdArrForm: use Fixity via extension point
Torsten Schmits (@torsten.schmits)
gitlab at gitlab.haskell.org
Mon Aug 19 15:41:52 UTC 2024
Torsten Schmits pushed to branch wip/T24634-oneshot-bytecode at Glasgow Haskell Compiler / GHC
Commits:
d2648289 by romes at 2024-07-30T01:38:12-04:00
TTG HsCmdArrForm: use Fixity via extension point
Also migrate Fixity from GHC.Hs to Language.Haskell.Syntax
since it no longer uses any GHC-specific data types.
Fixed arrow desugaring bug. (This was dead code before.)
Remove mkOpFormRn, it is also dead code, only used in the arrow
desugaring now removed.
Co-authored-by: Fabian Kirchner <kirchner at posteo.de>
Co-authored-by: Alan Zimmerman <alan.zimm at gmail.com>
- - - - -
e258ad54 by Matthew Pickering at 2024-07-30T01:38:48-04:00
ghcup-metadata: More metadata fixes
* Incorrect version range on the alpine bindists
* Missing underscore in "unknown_versioning"
Fixes #25119
- - - - -
4a388831 by Cheng Shao at 2024-07-30T19:00:56+02:00
compiler: always generate dynamic stub objects when generating bytecode
When foreign stub objects are compiled during bytecode generation
(e.g. when using whole core bindings), ensure they are dynamic so they
can be properly loaded.
- - - - -
11fe7708 by Cheng Shao at 2024-07-30T19:00:56+02:00
compiler: generate stub objects before writing iface
This commit promotes foreign stub compilation a bit earlier before we
actually write iface, to make it possible to actually serialize them
into the final iface when compiling with
`-fwrite-if-simplified-core`. Also ensures dynamic stub objects are
generated if we're compiling with `-fwrite-if-simplified-core`.
- - - - -
6298bc18 by Torsten Schmits at 2024-08-02T14:45:30+02:00
try without forced dynamic
- - - - -
48b11e8e by Cheng Shao at 2024-08-02T14:45:30+02:00
compiler: add mi_stub_objs to ModIface
This commit adds the mi_stub_objs field to ModIface, representing
serialized foreign stub dynamic objects that can be reloaded later
when compiling a downstream module with `-fprefer-byte-code` that
loads whole core bindings from an upstream module that requires
foreign stubs, see #24634 for such an example.
- - - - -
3a246b7f by Cheng Shao at 2024-08-02T14:45:54+02:00
compiler: serialize foreign stub dynamic objects in interface file when compiling with -fwrite-if-simplified-core
This commit makes the compiler serialize foreign stub dynamic objects
in mi_stub_objs when compiling with -fwrite-if-simplified-core. This
is needed when we compile a downstream module with -fprefer-byte-code,
in which case we want to make use of whole core bindings in upstream
modules instead of having to load their dynamic objects, but the
foreign stub information has been lost across different ghc
invocations previously. Hence the fix in this commit. See #24634 for
such an example.
- - - - -
1da97520 by Cheng Shao at 2024-08-05T14:42:02+02:00
testsuite: fix T24634
This commit fixes T24634 and marks it as unbroken.
- - - - -
f3b9e3c9 by Torsten Schmits at 2024-08-19T15:24:39+02:00
Store ForeignStubs and foreign C files in interfaces
Metric Decrease:
T13701
- - - - -
f968cecf by Torsten Schmits at 2024-08-19T15:24:39+02:00
normalize the API for Linkable and Unlinked a bit
- - - - -
c2ef0359 by Cheng Shao at 2024-08-19T17:41:14+02:00
Link bytecode from interface-stored core bindings in oneshot mode
If the flag `-fprefer-byte-code` is given when compiling a module
containing TH, GHC will use core bindings stored in interfaces to
compile and link bytecode for splices.
This was only implemented for `--make` mode initially, so this commit
adds the same mechanism to oneshot mode (`-c`).
- - - - -
30 changed files:
- .gitlab/rel_eng/mk-ghcup-metadata/mk_ghcup_metadata.py
- compiler/GHC/Cmm/CLabel.hs
- compiler/GHC/CoreToIface.hs
- compiler/GHC/Driver/Backpack.hs
- compiler/GHC/Driver/CodeOutput.hs
- compiler/GHC/Driver/Main.hs
- + compiler/GHC/Driver/Main.hs-boot
- compiler/GHC/Driver/Pipeline.hs
- compiler/GHC/Driver/Pipeline/Execute.hs
- + compiler/GHC/Hs/Basic.hs
- compiler/GHC/Hs/Expr.hs
- compiler/GHC/Hs/Instances.hs
- compiler/GHC/HsToCore/Arrows.hs
- compiler/GHC/HsToCore/Ticks.hs
- compiler/GHC/HsToCore/Usage.hs
- compiler/GHC/Iface/Ext/Ast.hs
- compiler/GHC/Iface/Load.hs
- compiler/GHC/Iface/Make.hs
- compiler/GHC/Iface/Recomp.hs
- compiler/GHC/IfaceToCore.hs
- compiler/GHC/Linker/Deps.hs
- compiler/GHC/Linker/Loader.hs
- compiler/GHC/Linker/Types.hs
- compiler/GHC/Parser.y
- compiler/GHC/Parser/PostProcess.hs
- compiler/GHC/Rename/Expr.hs
- compiler/GHC/Rename/HsType.hs
- compiler/GHC/Runtime/Interpreter.hs
- compiler/GHC/StgToJS/Linker/Linker.hs
- compiler/GHC/Tc/Gen/Arrow.hs
The diff was not included because it is too large.
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b0026fd3686a842faaba516076bd514060a9f10c...c2ef0359faea69f4426f9d60e2a03cb953e1c17a
--
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/b0026fd3686a842faaba516076bd514060a9f10c...c2ef0359faea69f4426f9d60e2a03cb953e1c17a
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/20240819/d0c1a97f/attachment.html>
More information about the ghc-commits
mailing list