[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 9 commits: ghc: Distinguish between having an interpreter and having an internal one
Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC Commits: 14bc71e4 by Sven Tennie at 2026-04-28T13:22:47-04:00 ghc: Distinguish between having an interpreter and having an internal one Actually, these are related but different things: - ghc can run an interpreter (either internal or external) - ghc is compiled with an internal interpreter Splitting the logic solves compiler warnings and expresses the intent better. - - - - - df691563 by Vladislav Zavialov at 2026-04-28T13:23:29-04:00 Refactor HsWildCardTy to use HoleKind (#27111) The payload of this patch is that the extension fields of HsWildCardTy and HsHole now match: type instance XWildCardTy Ghc{Ps,Rn} = HoleKind type instance XHole Ghc{Ps,Rn} = HoleKind This is progress towards unification of HsExpr and HsType. Test case: T25121_status In addition to that, exact-printing of infix holes is fixed. Test case: PprInfixHole - - - - - f3485446 by fendor at 2026-04-28T13:24:12-04:00 Expose startupHpc as an rts symbol - - - - - 28f07d70 by fendor at 2026-04-28T13:24:12-04:00 Make HPC work with bytecode interpreter Add support to generate .tix files from bytecode objects and the bytecode interpreter. Conceptually, we insert HPC ticks into the bytecode similar to how we insert breakpoints. HPC and breakpoints do not share the same tick array but we use a separate tick-array for hpc/breakpoint ticks during bytecode generation. We teach the bytecode interpreter to handle hpc ticks. The implementation is quite trivial, simply increment the counter in the global hpc_ticks array for the respective module. This hpc_ticks array is generated as part of the `CStub`, so we can rely on it existing. A tricky bit is "registering" a bytecode object for HPC instrumentation. In the compiled case, this is achieved via CStub and initializer/finalizers `.init` sections which are called when the executable is run. After the initializers have been invoked, which is before `hs_init_ghc`, we then call `startup_hpc` in `hs_init_ghc` iff any modules were "registered" for hpc instrumentation via `hs_hpc_module`. Since bytecode objects are loaded after starting up GHCi, this workflow doesn't work for supporting `hpc` and the `hpc` run-time is never started, even if a module is added for instrumentation. We fix this issue by employing the same technique as is for `SptEntry`s: * We introduce a new field to `CompiledByteCode`, called `ByteCodeHpcInfo` which contains enough information to call `hs_hpc_module`, allowing us to register the module for `hpc` instrumentation`. * After registering the module, we unconditionally call `startupHpc`, to make sure the .tix file is written. Calling `startupHpc` multiple times is safe. Calling `hs_hpc_module` multiple times for the same module is also safe. If we didn't register the hpc module in this way, evaluating a bytecode object instrumented with `-fhpc` without registering it in the `hpc` run-time will simply not generate any `.tix` files for this bytecode object. However, this shouldn't happen if everything is set up correctly. Closes #27036 - - - - - 950879f0 by Vladislav Zavialov at 2026-04-28T13:24:55-04:00 Move NamespaceSpecifier from x-fields into the AST proper (#26678) This refactoring moves NamespaceSpecifier out of extension fields and into the AST proper, as it is part of the user-written source, and is not pass-specific. Summary of changes: * Move NamespaceSpecifier from GHC/Hs/Basic.hs to Language/Haskell/Syntax/ImpExp.hs and parameterise it by the compiler pass, creating the necessary extension points * Move NamespaceSpecifier out of XFixitySig into FixitySig * Move NamespaceSpecifier out of XIEThingAll (IEThingAllExt) into IEThingAll * Move NamespaceSpecifier out of XIEWholeNamespace (IEWholeNamespaceExt) into IEWholeNamespace This is a pure refactoring with no change in behaviour. - - - - - 9797052b by Simon Peyton Jones at 2026-04-28T13:25:37-04:00 Fix assertion check in checkResultTy As #27210 shows, the assertion was a little bit too eager. I refactored a bit by moving some code from GHC.Tc.Gen.App to GHC.Tc.Utils.Unify; see the new function tcSubTypeApp, which replaces tcSubTypeDS - - - - - 9f3ac00c by David Eichmann at 2026-04-28T13:57:13-04:00 Hadrian: withResponseFile outputs response file when verbodity is Verbose At the Verbose verbosity, shake will display full commandlines. With the use of response files, the full command is hidden. That makes it hard to run the command manually. This commit outputs the contents of the response file so that that full command can be recreated and also hints at the use of the --keep-response-files hadrian flag. - - - - - 6c01446b by Duncan Coutts at 2026-04-28T13:57:14-04:00 Use response files for hadrian linking with ghc (support long command lines) In future support for windows dynamic linking, we expect long command lines for linking dll files with ghc. Experiments with dynamic linking the ghc-internal library yielded a link command well over 32kb. We did not encounter this before for static libs, since we already use ar's @file feature (if available, which it is for the llvm toolchain). Co-authored-by: David Eichmann <davide@well-typed.com> - - - - - 2952c860 by Cheng Shao at 2026-04-28T13:57:15-04:00 compiler: avoid unique OccNames for internal Names in bytecode objects This patch improves bytecode object serialization logic by avoiding the construction of unique `OccName`s when serializing/deserializing internal `Name`s. Closes #27213. ------------------------- Metric Decrease: LinkableUsage01 ------------------------- - - - - - 112 changed files: - + changelog.d/T19174.md - + changelog.d/bytecode-interpreter-hpc-support - + changelog.d/ghc-api-holes-ast-27111 - + changelog.d/ghc-api-namespace-specifier-26678 - compiler/GHC/ByteCode/Asm.hs - compiler/GHC/ByteCode/Binary.hs - compiler/GHC/ByteCode/Instr.hs - compiler/GHC/ByteCode/Types.hs - compiler/GHC/Driver/Backend.hs - compiler/GHC/Driver/CodeOutput.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Session.hs - compiler/GHC/Hs/Basic.hs - compiler/GHC/Hs/Binds.hs - compiler/GHC/Hs/Decls.hs - compiler/GHC/Hs/Expr.hs-boot - compiler/GHC/Hs/ImpExp.hs - compiler/GHC/Hs/Type.hs - compiler/GHC/HsToCore.hs - compiler/GHC/HsToCore/Coverage.hs - compiler/GHC/HsToCore/Docs.hs - compiler/GHC/HsToCore/Quote.hs - compiler/GHC/HsToCore/Ticks.hs - compiler/GHC/Iface/Ext/Ast.hs - compiler/GHC/Iface/Tidy.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Parser.y - compiler/GHC/Parser/PostProcess.hs - compiler/GHC/Parser/PostProcess/Haddock.hs - compiler/GHC/Rename/Bind.hs - compiler/GHC/Rename/Env.hs - compiler/GHC/Rename/HsType.hs - compiler/GHC/Rename/Module.hs - compiler/GHC/Rename/Names.hs - compiler/GHC/Rename/Pat.hs - compiler/GHC/Runtime/Interpreter.hs - compiler/GHC/StgToByteCode.hs - compiler/GHC/Tc/Errors/Ppr.hs - compiler/GHC/Tc/Errors/Types.hs - compiler/GHC/Tc/Gen/App.hs - compiler/GHC/Tc/Gen/Export.hs - compiler/GHC/Tc/Gen/Head.hs - compiler/GHC/Tc/Gen/HsType.hs - compiler/GHC/Tc/Gen/Pat.hs - compiler/GHC/Tc/Utils/Unify.hs - compiler/GHC/ThToHs.hs - compiler/GHC/Types/HpcInfo.hs - compiler/GHC/Types/Name/Reader.hs - compiler/GHC/Unit/Module/ModGuts.hs - compiler/Language/Haskell/Syntax/Binds.hs - compiler/Language/Haskell/Syntax/Decls.hs - compiler/Language/Haskell/Syntax/Extension.hs - compiler/Language/Haskell/Syntax/ImpExp.hs - ghc/GHC/Driver/Session/Mode.hs - ghc/GHCi/UI.hs - ghc/Main.hs - ghc/ghc-bin.cabal.in - hadrian/src/Builder.hs - hadrian/src/Hadrian/Builder.hs - hadrian/src/Hadrian/Utilities.hs - hadrian/src/Settings/Builders/Ghc.hs - hadrian/src/Settings/Packages.hs - + libraries/ghci/GHCi/Coverage.hs - libraries/ghci/GHCi/Message.hs - libraries/ghci/GHCi/Run.hs - libraries/ghci/ghci.cabal.in - rts/Disassembler.c - rts/Hpc.c - rts/Interpreter.c - rts/RtsSymbols.c - rts/include/rts/Bytecodes.h - testsuite/tests/ghc-api/T25121_status.stdout - testsuite/tests/haddock/should_compile_flag_haddock/T17544_kw.stderr - testsuite/tests/hpc/Makefile - testsuite/tests/hpc/T17073.stdout → testsuite/tests/hpc/T17073a.stdout - + testsuite/tests/hpc/T17073b.stdout - testsuite/tests/hpc/T20568.stdout → testsuite/tests/hpc/T20568a.stdout - + testsuite/tests/hpc/T20568b.stdout - testsuite/tests/hpc/all.T - testsuite/tests/hpc/fork/Makefile - testsuite/tests/hpc/function/Makefile - testsuite/tests/hpc/function/test.T - + testsuite/tests/hpc/function/tough1.stderr - + testsuite/tests/hpc/function/tough1.stdout - testsuite/tests/hpc/function2/test.T - + testsuite/tests/hpc/function2/tough3.script - + testsuite/tests/hpc/ghc_ghci/BytecodeMain.hs - testsuite/tests/hpc/ghc_ghci/Makefile - + testsuite/tests/hpc/ghc_ghci/hpc_ghc_ghci_bytecode.stdout - + testsuite/tests/hpc/ghc_ghci/hpc_ghci01.stdout - + testsuite/tests/hpc/ghc_ghci/hpc_ghci02.stdout - testsuite/tests/hpc/ghc_ghci/test.T - testsuite/tests/hpc/simple/Makefile - + testsuite/tests/hpc/simple/hpc002.hs - + testsuite/tests/hpc/simple/hpc002.stdout - + testsuite/tests/hpc/simple/hpc003.hs - + testsuite/tests/hpc/simple/hpc003.script - + testsuite/tests/hpc/simple/hpc003.stdout - testsuite/tests/hpc/simple/test.T - testsuite/tests/parser/should_compile/T20846.stderr - testsuite/tests/printer/Makefile - + testsuite/tests/printer/PprInfixHole.hs - testsuite/tests/printer/all.T - + testsuite/tests/typecheck/should_fail/T27210.hs - + testsuite/tests/typecheck/should_fail/T27210.stderr - testsuite/tests/typecheck/should_fail/all.T - utils/check-exact/ExactPrint.hs - utils/haddock/haddock-api/src/Haddock/Backends/Hoogle.hs - utils/haddock/haddock-api/src/Haddock/Convert.hs - utils/haddock/haddock-api/src/Haddock/GhcUtils.hs - utils/haddock/haddock-api/src/Haddock/Interface/Rename.hs - utils/haddock/haddock-api/src/Haddock/Types.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f88ba364af31618f7a8f9ed0b23d3f5... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f88ba364af31618f7a8f9ed0b23d3f5... You're receiving this email because of your account on gitlab.haskell.org.
participants (1)
-
Marge Bot (@marge-bot)