- ghc-commits - Haskell.org

[Git][ghc/ghc][wip/fendor/infoprov-id] 17 commits: Testsuite: pass ext-interp test way (#26552)
by Hannes Siebenhandl (＠fendor) 12 Nov '25

12 Nov '25

Hannes Siebenhandl pushed to branch wip/fendor/infoprov-id at Glasgow Haskell Compiler / GHC Commits: ac7b737e by Sylvain Henry at 2025-11-07T17:22:51-05:00 Testsuite: pass ext-interp test way (#26552) Note that some tests are still marked as broken with the ext-interp way (see #26552 and #14335) - - - - - 3c2f4bb4 by sheaf at 2025-11-11T11:47:28-05:00 Preserve user-written kinds in data declarations This commit ensures that we preserve the user-written kind for data declarations, e.g. in type T2T = Type -> Type type D :: T2T data D a where { .. } that we preserve the user-written kind of D as 'T2T', instead of expanding the type synonym 'T2T' during kind checking. We do this by storing 'tyConKind' separately from 'tyConResKind'. This means that 'tyConKind' is not necessarily equal to 'mkTyConKind binders res_kind', as e.g. in the above example the former is 'T2T' while the latter is 'Type -> Type'. This is explained in Note [Preserve user-written TyCon kind] in GHC.Core.TyCon. This is particularly important for Haddock, as the kinds stored in interface files affect the generated documentation, and we want to preserve the user-written types as much as possible. - - - - - 19859584 by sheaf at 2025-11-11T11:47:28-05:00 Store user-written datacon tvs in interface files This commit ensures we store the user-written quantified type variables of data constructors in interface files, e.g. in data D a where MkD1 :: forall x. x -> D x MkD2 :: forall u v. u -> v -> D v The previous behaviour was to rename the universal variables to match the universal variables of the data constructor. This was undesirable because the names that end up in interface files end up mattering for generated Haddock documentation; it's better to preserve the user-written type variables. Moreover, the universal variables may not have been user-written at all, e.g. in an example such as: type T2T = Type -> Type data G :: T2T where MkG :: forall x. D x Here GHC will invent the type variable name 'a' for the first binder of the TyCon G. We really don't want to then rename the user-written 'x' into the generated 'a'. - - - - - 034b2056 by sheaf at 2025-11-11T11:47:28-05:00 DataCon univ_tvs names: pick TyCon over inferred This commit changes how we compute the names of universal type variables in GADT data constructors. This augments the existing logic that chose which type variable name to use, in GHC.Tc.TyCl.mkGADTVars. We continue to prefer DataCon tv names for user-written binders, but we now prefer TyCon tv names for inferred (non-user-written) DataCon binders. This makes a difference in examples such as: type (:~~:) :: k1 -> k2 -> Type data a :~~: b where HRefl :: a :~~: a Before this patch, we ended up giving HRefl the type: forall {k2}. forall (a :: k2). a :~~: a whereas we now give it the type: forall {k1}. forall (a :: k1). a :~~: a The important part isn't really 'k1' or 'k2', but more that the inferred type variable names of the DataCon can be arbitrary/unpredictable (as they are chosen by GHC and depend on how unification proceeds), so it's much better to use the more predictable TyCon type variable names. - - - - - 95078d00 by sheaf at 2025-11-11T11:47:28-05:00 Backpack Rename: use explicit record construction This commit updates the Backpack boilerplate in GHC.Iface.Rename to use explicit record construction rather than record update. This makes sure that the code stays up to date when the underlying constructors change (e.g. new fields are added). The rationale is further explained in Note [Prefer explicit record construction]. - - - - - 2bf36263 by sheaf at 2025-11-11T11:47:28-05:00 Store # eta binders in TyCon and use for Haddock This commit stores the number of TyCon binders that were introduced by eta-expansion (by the function GHC.Tc.Gen.HsType.splitTyConKind). This is then used to pretty-print the TyCon as the user wrote it, e.g. for type Effect :: (Type -> Type) -> Type -> Type data State s :: Effect where {..} -- arity 3 GHC will eta-expand the data declaration to data State s a b where {..} but also store in the 'TyCon' that the number of binders introduced by this eta expansion is 2. This allows us, in 'Haddock.Convert.synifyTyConKindSig', to recover the original user-written syntax, preserving the user's intent in Haddock documentation. See Note [Inline kind signatures with GADTSyntax] in Haddock.Convert. - - - - - 6c91582f by Matthew Pickering at 2025-11-11T11:48:12-05:00 driver: Properly handle errors during LinkNode steps Previously we were not properly catching errors during the LinkNode step (see T9930fail test). This is fixed by wrapping the `LinkNode` action in `wrapAction`, the same handler which is used for module compilation. Fixes #26496 - - - - - e1e1eb32 by Matthew Pickering at 2025-11-11T11:48:54-05:00 driver: Remove unecessary call to hscInsertHPT This call was left-over from e9445c013fbccf9318739ca3d095a3e0a2e1be8a If you follow the functions which call `upsweep_mod`, they immediately add the interface to the HomePackageTable when `upsweep_mod` returns. - - - - - b22777d4 by ARATA Mizuki at 2025-11-11T11:49:44-05:00 LLVM backend: Pass the +evex512 attribute to LLVM 18+ if -mavx512f is set The newer LLVM requires the +evex512 attribute to enable use of ZMM registers. LLVM exhibits a backward-compatible behavior if the cpu is `x86-64`, but not if `penryn`. Therefore, on macOS, where the cpu is set to `penryn`, we need to explicitly pass +evex512. Fixes #26410 - - - - - 6ead7d06 by Vladislav Zavialov at 2025-11-11T11:50:26-05:00 Comments only in GHC.Parser.PostProcess.Haddock Remove outdated Note [Register keyword location], as the issue it describes was addressed by commit 05eb50dff2fcc78d025e77b9418ddb369db49b9f. - - - - - 43fa8be8 by sheaf at 2025-11-11T11:51:18-05:00 localRegistersConflict: account for assignment LHS This commit fixes a serious oversight in GHC.Cmm.Sink.conflicts, specifically the code that computes which local registers conflict between an assignment and a Cmm statement. If we have: assignment: <local_reg> = <expr> node: <local_reg> = <other_expr> then clearly the two conflict, because we cannot move one statement past the other, as they assign two different values to the same local register. (Recall that 'conflicts (local_reg,expr) node' is False if and only if the assignment 'local_reg = expr' can be safely commuted past the statement 'node'.) The fix is to update 'GHC.Cmm.Sink.localRegistersConflict' to take into account the following two situations: (1) 'node' defines the LHS local register of the assignment, (2) 'node' defines a local register used in the RHS of the assignment. The bug is precisely that we were previously missing condition (1). Fixes #26550 - - - - - 79dfcfe0 by sheaf at 2025-11-11T11:51:18-05:00 Update assigned register format when spilling When we come to spilling a register to put new data into it, in GHC.CmmToAsm.Reg.Linear.allocRegsAndSpill_spill, we need to: 1. Spill the data currently in the register. That is, do a spill with a format that matches what's currently in the register. 2. Update the register assignment, allocating a virtual register to this real register, but crucially **updating the format** of this assignment. Due to shadowing in the Haskell code for allocRegsAndSpill_spill, we were mistakenly re-using the old format. This could lead to a situation where: a. We were using xmm6 to store a Double#. b. We want to store a DoubleX2# into xmm6, so we spill the current content of xmm6 to the stack using a scalar move (correct). c. We update the register assignment, but we fail to update the format of the assignment, so we continue to think that xmm6 stores a Double# and not a DoubleX2#. d. Later on, we need to spill xmm6 because it is getting clobbered by another instruction. We then decide to only spill the lower 64 bits of the register, because we still think that xmm6 only stores a Double# and not a DoubleX2#. Fixes #26542 - - - - - aada5db9 by ARATA Mizuki at 2025-11-11T11:52:07-05:00 Fix the order of spill/reload instructions The AArch64 NCG could emit multiple instructions for a single spill/reload, but their order was not consistent between the definition and a use. Fixes #26537 Co-authored-by: sheaf <sam.derbyshire(a)gmail.com> - - - - - 64ec82ff by Andreas Klebinger at 2025-11-11T11:52:48-05:00 Add hpc to release script - - - - - 741da00c by Ben Gamari at 2025-11-12T03:38:20-05:00 template-haskell: Better describe getQ semantics Clarify that the state is a type-indexed map, as suggested by #26484. - - - - - 8b080e04 by ARATA Mizuki at 2025-11-12T03:39:11-05:00 Fix incorrect markups in the User's Guide * Correct markup for C--: "C-\-" in reST * Fix internal links * Fix code highlighting * Fix inline code: Use ``code`` rather than `code` * Remove extra backslashes Fixes #16812 Co-authored-by: sheaf <sam.derbyshire(a)gmail.com> - - - - - 04a90100 by fendor at 2025-11-12T12:03:18+01:00 Add 'ipId' to 'InfoProv' and add decoders The 'InfoProv' was changed to use a stable Id, for the eventlog and for general identification. This change simply exposes the stable id and allows you to quickly query it. - - - - - 131 changed files: - .gitlab/rel_eng/upload_ghc_libs.py - compiler/GHC/Builtin/Types.hs - compiler/GHC/Builtin/Types/Literals.hs - compiler/GHC/Cmm/Sink.hs - compiler/GHC/CmmToAsm/Reg/Linear.hs - compiler/GHC/CmmToAsm/Reg/Liveness.hs - compiler/GHC/Core/TyCon.hs - compiler/GHC/Core/Type.hs - compiler/GHC/Driver/Make.hs - compiler/GHC/Driver/Pipeline/Execute.hs - compiler/GHC/Iface/Decl.hs - compiler/GHC/Iface/Rename.hs - compiler/GHC/Iface/Syntax.hs - compiler/GHC/IfaceToCore.hs - compiler/GHC/Parser/PostProcess/Haddock.hs - compiler/GHC/Tc/Gen/HsType.hs - compiler/GHC/Tc/TyCl.hs - compiler/GHC/Tc/TyCl/Build.hs - compiler/GHC/Tc/TyCl/Instance.hs - docs/users_guide/bugs.rst - docs/users_guide/debug-info.rst - docs/users_guide/debugging.rst - docs/users_guide/extending_ghc.rst - docs/users_guide/exts/arrows.rst - docs/users_guide/exts/derive_any_class.rst - docs/users_guide/exts/deriving_extra.rst - docs/users_guide/exts/deriving_inferred.rst - docs/users_guide/exts/deriving_strategies.rst - docs/users_guide/exts/gadt.rst - docs/users_guide/exts/generics.rst - docs/users_guide/exts/overloaded_labels.rst - docs/users_guide/exts/overloaded_strings.rst - docs/users_guide/exts/pattern_synonyms.rst - docs/users_guide/exts/poly_kinds.rst - docs/users_guide/exts/primitives.rst - docs/users_guide/exts/rank_polymorphism.rst - docs/users_guide/exts/rebindable_syntax.rst - docs/users_guide/exts/required_type_arguments.rst - docs/users_guide/exts/scoped_type_variables.rst - docs/users_guide/exts/standalone_deriving.rst - docs/users_guide/exts/template_haskell.rst - docs/users_guide/exts/tuple_sections.rst - docs/users_guide/exts/type_data.rst - docs/users_guide/exts/type_defaulting.rst - docs/users_guide/gone_wrong.rst - docs/users_guide/hints.rst - docs/users_guide/javascript.rst - docs/users_guide/phases.rst - docs/users_guide/profiling.rst - docs/users_guide/separate_compilation.rst - docs/users_guide/using.rst - docs/users_guide/wasm.rst - docs/users_guide/win32-dlls.rst - libraries/base/tests/all.T - libraries/ghc-internal/src/GHC/Internal/InfoProv/Types.hsc - libraries/ghc-internal/src/GHC/Internal/TH/Monad.hs - libraries/ghci/GHCi/Message.hs - testsuite/driver/testlib.py - testsuite/tests/backpack/should_fail/T19244a.stderr - + testsuite/tests/codeGen/should_run/T26537.hs - + testsuite/tests/codeGen/should_run/T26537.stdout - testsuite/tests/codeGen/should_run/all.T - testsuite/tests/dependent/should_fail/T11334b.stderr - testsuite/tests/driver/T20696/all.T - testsuite/tests/driver/fat-iface/all.T - testsuite/tests/generics/T10604/T10604_deriving.stderr - testsuite/tests/ghc-e/should_fail/T9930fail.stderr - testsuite/tests/ghc-e/should_fail/all.T - testsuite/tests/ghci.debugger/scripts/print012.stdout - testsuite/tests/ghci/scripts/T10321.stdout - testsuite/tests/ghci/scripts/T24459.stdout - testsuite/tests/ghci/scripts/T7730.stdout - testsuite/tests/ghci/scripts/ghci065.stdout - testsuite/tests/haddock/should_compile_flag_haddock/T17544_kw.hs - testsuite/tests/haddock/should_compile_flag_haddock/T17544_kw.stderr - testsuite/tests/interface-stability/base-exports.stdout - testsuite/tests/interface-stability/base-exports.stdout-javascript-unknown-ghcjs - testsuite/tests/interface-stability/base-exports.stdout-mingw32 - testsuite/tests/interface-stability/base-exports.stdout-ws-32 - testsuite/tests/profiling/should_run/staticcallstack001.stdout - testsuite/tests/profiling/should_run/staticcallstack002.stdout - testsuite/tests/rename/should_fail/rnfail055.stderr - testsuite/tests/rts/ipe/T24005/t24005.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables01.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables02.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables03.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables04.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables05.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables06.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables07.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables08.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables09.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables10.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables11.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables12.stdout - testsuite/tests/rts/ipe/distinct-tables/distinct_tables13.stdout - testsuite/tests/saks/should_compile/saks023.stdout - testsuite/tests/saks/should_compile/saks034.stdout - testsuite/tests/saks/should_compile/saks035.stdout - testsuite/tests/showIface/Makefile - + testsuite/tests/showIface/T26246a.hs - + testsuite/tests/showIface/T26246a.stdout - testsuite/tests/showIface/all.T - + testsuite/tests/simd/should_run/T26410_ffi.hs - + testsuite/tests/simd/should_run/T26410_ffi.stdout - + testsuite/tests/simd/should_run/T26410_ffi_c.c - + testsuite/tests/simd/should_run/T26410_prim.hs - + testsuite/tests/simd/should_run/T26410_prim.stdout - + testsuite/tests/simd/should_run/T26542.hs - + testsuite/tests/simd/should_run/T26542.stdout - + testsuite/tests/simd/should_run/T26550.hs - + testsuite/tests/simd/should_run/T26550.stdout - testsuite/tests/simd/should_run/all.T - testsuite/tests/splice-imports/all.T - testsuite/tests/typecheck/T16127/T16127.stderr - testsuite/tests/typecheck/should_compile/T22560d.stdout - testsuite/tests/typecheck/should_fail/T15629.stderr - utils/haddock/haddock-api/src/Haddock/Convert.hs - utils/haddock/html-test/ref/Bug1004.html - utils/haddock/html-test/ref/Bug1050.html - + utils/haddock/html-test/ref/Bug26246.html - utils/haddock/html-test/ref/Bug85.html - utils/haddock/html-test/ref/Bug923.html - utils/haddock/html-test/ref/BundledPatterns.html - utils/haddock/html-test/ref/BundledPatterns2.html - utils/haddock/html-test/ref/ConstructorPatternExport.html - utils/haddock/html-test/ref/GADTRecords.html - utils/haddock/html-test/ref/LinearTypes.html - utils/haddock/html-test/ref/PromotedTypes.html - + utils/haddock/html-test/src/Bug26246.hs - utils/haddock/latex-test/ref/LinearTypes/LinearTypes.tex The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/58644c6db8155e82cf5258af47afb2… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/58644c6db8155e82cf5258af47afb2… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/bytecode-library-combined] Load bytecode libraries to satisfy package dependencies
by Matthew Pickering (＠mpickering) 12 Nov '25

12 Nov '25

Matthew Pickering pushed to branch wip/bytecode-library-combined at Glasgow Haskell Compiler / GHC Commits: c66a5039 by Matthew Pickering at 2025-11-12T10:27:07+00:00 Load bytecode libraries to satisfy package dependencies This commit allows you to use a bytecode library to satisfy a package dependency when using the interpreter. If a user enables `-fprefer-byte-code`, then if a package provides a bytecode library, that will be loaded and used to satisfy the dependency. The main change is to separate the relevant parts of the `LoaderState` into external and home package byte code. Bytecode is loaded into either the home package or external part (similar to HPT/EPS split), HPT bytecode can be unloaded. External bytecode is never unloaded. The unload function has also only been called with an empty list of "stable linkables" for a long time. It has been modified to directly implement a complete unloading of the home package bytecode linkables. At the moment, the bytecode libraries are found in the "library-dirs" field from the package description. In the future when `Cabal` implements support for "bytecode-library-dirs" field, we can read the bytecode libraries from there. No changes to the Cabal submodule are necessary at the moment. Four new tests are added in testsuite/tests/cabal, which generate fake package descriptions and test loading the libraries into GHCi. Fixes #26298 - - - - - 36 changed files: - compiler/GHC/ByteCode/Linker.hs - compiler/GHC/Driver/Backpack.hs - compiler/GHC/Driver/Make.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Linker/Types.hs - compiler/GHC/Runtime/Debugger.hs - compiler/GHC/Runtime/Eval.hs - compiler/GHC/Unit/Info.hs - compiler/GHC/Unit/State.hs - docs/users_guide/phases.rst - libraries/ghc-boot/GHC/Unit/Database.hs - testsuite/config/ghc - testsuite/mk/boilerplate.mk - + testsuite/tests/cabal/Bytecode.hs - + testsuite/tests/cabal/BytecodeForeign.c - + testsuite/tests/cabal/BytecodeForeign.hs - testsuite/tests/cabal/Makefile - testsuite/tests/cabal/all.T - + testsuite/tests/cabal/bytecode.pkg - + testsuite/tests/cabal/bytecode.script - + testsuite/tests/cabal/bytecode_foreign.pkg - + testsuite/tests/cabal/bytecode_foreign.script - testsuite/tests/cabal/ghcpkg03.stderr - testsuite/tests/cabal/ghcpkg03.stderr-mingw32 - testsuite/tests/cabal/ghcpkg05.stderr - testsuite/tests/cabal/ghcpkg05.stderr-mingw32 - + testsuite/tests/cabal/pkg_bytecode.stderr - + testsuite/tests/cabal/pkg_bytecode.stdout - + testsuite/tests/cabal/pkg_bytecode_foreign.stderr - + testsuite/tests/cabal/pkg_bytecode_foreign.stdout - + testsuite/tests/cabal/pkg_bytecode_with_gbc.stderr - + testsuite/tests/cabal/pkg_bytecode_with_gbc.stdout - + testsuite/tests/cabal/pkg_bytecode_with_o.stderr - + testsuite/tests/cabal/pkg_bytecode_with_o.stdout - testsuite/tests/driver/bytecode-object/all.T - utils/ghc-pkg/Main.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/c66a5039366b4d835abeefc27afcc72… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/c66a5039366b4d835abeefc27afcc72… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][master] Fix incorrect markups in the User's Guide
by Marge Bot (＠marge-bot) 12 Nov '25

12 Nov '25

Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC Commits: 8b080e04 by ARATA Mizuki at 2025-11-12T03:39:11-05:00 Fix incorrect markups in the User's Guide * Correct markup for C--: "C-\-" in reST * Fix internal links * Fix code highlighting * Fix inline code: Use ``code`` rather than `code` * Remove extra backslashes Fixes #16812 Co-authored-by: sheaf <sam.derbyshire(a)gmail.com> - - - - - 34 changed files: - docs/users_guide/bugs.rst - docs/users_guide/debug-info.rst - docs/users_guide/debugging.rst - docs/users_guide/extending_ghc.rst - docs/users_guide/exts/arrows.rst - docs/users_guide/exts/derive_any_class.rst - docs/users_guide/exts/deriving_extra.rst - docs/users_guide/exts/deriving_inferred.rst - docs/users_guide/exts/deriving_strategies.rst - docs/users_guide/exts/gadt.rst - docs/users_guide/exts/generics.rst - docs/users_guide/exts/overloaded_labels.rst - docs/users_guide/exts/overloaded_strings.rst - docs/users_guide/exts/pattern_synonyms.rst - docs/users_guide/exts/poly_kinds.rst - docs/users_guide/exts/primitives.rst - docs/users_guide/exts/rank_polymorphism.rst - docs/users_guide/exts/rebindable_syntax.rst - docs/users_guide/exts/required_type_arguments.rst - docs/users_guide/exts/scoped_type_variables.rst - docs/users_guide/exts/standalone_deriving.rst - docs/users_guide/exts/template_haskell.rst - docs/users_guide/exts/tuple_sections.rst - docs/users_guide/exts/type_data.rst - docs/users_guide/exts/type_defaulting.rst - docs/users_guide/gone_wrong.rst - docs/users_guide/hints.rst - docs/users_guide/javascript.rst - docs/users_guide/phases.rst - docs/users_guide/profiling.rst - docs/users_guide/separate_compilation.rst - docs/users_guide/using.rst - docs/users_guide/wasm.rst - docs/users_guide/win32-dlls.rst The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/8b080e048d51defa19fe9a484ec922b… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/8b080e048d51defa19fe9a484ec922b… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][master] template-haskell: Better describe getQ semantics
by Marge Bot (＠marge-bot) 12 Nov '25

12 Nov '25

Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC Commits: 741da00c by Ben Gamari at 2025-11-12T03:38:20-05:00 template-haskell: Better describe getQ semantics Clarify that the state is a type-indexed map, as suggested by #26484. - - - - - 1 changed file: - libraries/ghc-internal/src/GHC/Internal/TH/Monad.hs Changes: ===================================== libraries/ghc-internal/src/GHC/Internal/TH/Monad.hs ===================================== @@ -904,8 +904,17 @@ addModFinalizer act = Q (qAddModFinalizer (unQ act)) addCorePlugin :: String -> Q () addCorePlugin plugin = Q (qAddCorePlugin plugin) --- | Get state from the 'Q' monad. Note that the state is local to the --- Haskell module in which the Template Haskell expression is executed. +-- | Get state from the 'Q' monad. The state maintained by 'Q' is isomorphic to +-- a type-indexed finite map. That is, +-- +-- @ +-- do putQ @Int 42 +-- putQ @Char 'a' +-- getQ @Int -- == (Just 42) +-- @ +-- +-- Note that the state is local to the Haskell module in which the Template +-- Haskell expression is executed. getQ :: Typeable a => Q (Maybe a) getQ = Q qGetQ View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/741da00c0b27ee515926d24f6354b71… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/741da00c0b27ee515926d24f6354b71… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 2 commits: template-haskell: Better describe getQ semantics
by Marge Bot (＠marge-bot) 12 Nov '25

12 Nov '25

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC Commits: 0f62414b by Ben Gamari at 2025-11-11T21:07:50-05:00 template-haskell: Better describe getQ semantics Clarify that the state is a type-indexed map, as suggested by #26484. - - - - - 31d13b0e by ARATA Mizuki at 2025-11-11T21:07:57-05:00 Fix incorrect markups in the User's Guide * Correct markup for C--: "C-\-" in reST * Fix internal links * Fix code highlighting * Fix inline code: Use ``code`` rather than `code` * Remove extra backslashes Fixes #16812 Co-authored-by: sheaf <sam.derbyshire(a)gmail.com> - - - - - 35 changed files: - docs/users_guide/bugs.rst - docs/users_guide/debug-info.rst - docs/users_guide/debugging.rst - docs/users_guide/extending_ghc.rst - docs/users_guide/exts/arrows.rst - docs/users_guide/exts/derive_any_class.rst - docs/users_guide/exts/deriving_extra.rst - docs/users_guide/exts/deriving_inferred.rst - docs/users_guide/exts/deriving_strategies.rst - docs/users_guide/exts/gadt.rst - docs/users_guide/exts/generics.rst - docs/users_guide/exts/overloaded_labels.rst - docs/users_guide/exts/overloaded_strings.rst - docs/users_guide/exts/pattern_synonyms.rst - docs/users_guide/exts/poly_kinds.rst - docs/users_guide/exts/primitives.rst - docs/users_guide/exts/rank_polymorphism.rst - docs/users_guide/exts/rebindable_syntax.rst - docs/users_guide/exts/required_type_arguments.rst - docs/users_guide/exts/scoped_type_variables.rst - docs/users_guide/exts/standalone_deriving.rst - docs/users_guide/exts/template_haskell.rst - docs/users_guide/exts/tuple_sections.rst - docs/users_guide/exts/type_data.rst - docs/users_guide/exts/type_defaulting.rst - docs/users_guide/gone_wrong.rst - docs/users_guide/hints.rst - docs/users_guide/javascript.rst - docs/users_guide/phases.rst - docs/users_guide/profiling.rst - docs/users_guide/separate_compilation.rst - docs/users_guide/using.rst - docs/users_guide/wasm.rst - docs/users_guide/win32-dlls.rst - libraries/ghc-internal/src/GHC/Internal/TH/Monad.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4c0b12090ed054cb72cd54cabe7b4d… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4c0b12090ed054cb72cd54cabe7b4d… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/T23162-part2] better still
by Simon Peyton Jones (＠simonpj) 12 Nov '25

12 Nov '25

Simon Peyton Jones pushed to branch wip/T23162-part2 at Glasgow Haskell Compiler / GHC Commits: 82df99d9 by Simon Peyton Jones at 2025-11-11T17:48:59+00:00 better still - - - - - 1 changed file: - compiler/GHC/Tc/Solver/FunDeps.hs Changes: ===================================== compiler/GHC/Tc/Solver/FunDeps.hs ===================================== @@ -545,24 +545,14 @@ mkTopClosedFamEqFDs :: CoAxiom Branched -> [TcType] -> Xi -> TcS [FunDepEqns] mkTopClosedFamEqFDs ax work_args work_rhs = do { let branches = fromBranches (coAxiomBranches ax) ; traceTcS "mkTopClosed" (ppr branches $$ ppr work_args $$ ppr work_rhs) - ; return (go branches) } + ; case filter relevant_branch branches of + [CoAxBranch { cab_tvs = qtvs, cab_lhs = lhs_tys }] + -> return [FDEqns { fd_qtvs = qtvs + , fd_eqs = zipWith Pair lhs_tys work_args }] + _ -> return [] } where - go :: [CoAxBranch] -> [FunDepEqns] - go [] = [] - - go (branch : later_branches) - | CoAxBranch { cab_tvs = qtvs, cab_lhs = lhs_tys - , cab_rhs = rhs_ty, cab_incomps = incomps } <- branch - , not (eqnIsIrrelevant lhs_tys rhs_ty work_args work_rhs) - , all irrelevant_branch incomps - , all irrelevant_branch later_branches - = [FDEqns { fd_qtvs = qtvs, fd_eqs = zipWith Pair lhs_tys work_args }] - - | otherwise - = go later_branches - - irrelevant_branch (CoAxBranch { cab_lhs = lhs_tys, cab_rhs = rhs_ty }) - = eqnIsIrrelevant lhs_tys rhs_ty work_args work_rhs + relevant_branch (CoAxBranch { cab_lhs = lhs_tys, cab_rhs = rhs_ty }) + = eqnIsRelevant lhs_tys rhs_ty work_args work_rhs mkTopOpenFamEqFDs :: TyCon -> [Bool] -> [TcType] -> Xi -> TcS [FunDepEqns] -- Implements (INJFAM:Wanted/top) @@ -738,13 +728,13 @@ getInertFamEqsFor fam_tc work_args work_rhs , eq_rhs = inert_rhs }) <- equal_ct_list , NomEq == eq_rel - , not (eqnIsIrrelevant inert_args inert_rhs work_args work_rhs) ] } + , eqnIsRelevant inert_args inert_rhs work_args work_rhs ] } -eqnIsIrrelevant :: [TcType] -> TcType +eqnIsRelevant :: [TcType] -> TcType -> [TcType] -> TcType -> Bool -eqnIsIrrelevant lhs_tys1 rhs_ty1 lhs_tys2 rhs_ty2 - = (rhs_ty1:lhs_tys1) `typeListsAreApart` (rhs_ty2:lhs_tys2) +eqnIsRelevant lhs_tys1 rhs_ty1 lhs_tys2 rhs_ty2 + = not ((rhs_ty1:lhs_tys1) `typeListsAreApart` (rhs_ty2:lhs_tys2)) {- Note [Type inference for type families with injectivity] View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/82df99d998eb356ccebbf2130bc6f79… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/82df99d998eb356ccebbf2130bc6f79… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/T26425] Wibbles
by Simon Peyton Jones (＠simonpj) 12 Nov '25

12 Nov '25

Simon Peyton Jones pushed to branch wip/T26425 at Glasgow Haskell Compiler / GHC Commits: fcc38ef7 by Simon Peyton Jones at 2025-11-11T17:47:50+00:00 Wibbles - - - - - 2 changed files: - compiler/GHC/Core/Opt/OccurAnal.hs - compiler/GHC/Core/Opt/Simplify/Iteration.hs Changes: ===================================== compiler/GHC/Core/Opt/OccurAnal.hs ===================================== @@ -660,18 +660,35 @@ through A, so it should have ManyOcc. Bear this case in mind! * In occ_env, the new (occ_join_points :: IdEnv OccInfoEnv) maps each in-scope non-recursive join point, such as `j` above, to a "zeroed form" of its RHS's usage details. The "zeroed form" + * has only occ_nested_lets in its domain (see (W5) below) * deletes ManyOccs * maps a OneOcc to OneOcc{ occ_n_br = 0 } - In our example, occ_join_points will be extended with + In our example, assuming `v` is locally-let-bound, occ_join_points will + be extended with [j :-> [v :-> OneOcc{occ_n_br=0}]] See `addJoinPoint` and (W5) below. * At an occurrence of a join point, we do everything as normal, but add in the UsageDetails from the occ_join_points. See mkOneOcc. -* Crucially, at the NonRec binding of the join point, in `occAnalBind`, we use - `combineJoinPointUDs`, not `andUDs` to combine the usage from the RHS with - the usage from the body. +* Crucially, at the NonRec binding of a join point `j`, in `occAnalBind`, + we use `combineJoinPointUDs`, not `andUDs` to combine the usage from the + RHS with the usage from the body. `combineJoinPointUDs` behaves like this: + + * For all variables than `occ_nested_lets`, use `andUDs`, just like for + any normal let-binding. + + * But for a variable `v` in `occ_nested_lets`, use `orUDs`: + - If `v` occurs `ManyOcc` in the join-point RHS, the variable won't be in + `occ_join_points`; but we'll get `ManyOcc` anyway. + - If `v` occurs `OneOcc` in the join-point RHS, the variable will be in + `occ_join_points` and we'll thereby get a `OneOcc{occ_n_br=0}` from + each of j's tail calls. We can `or` that with the `OncOcc{occ_n_br=n}` + from j's RHS. + + The only reason for `occ_nested_lets` is to reduce the size of the info + duplicate at each tail call; see (W5). It would sound to put *all* variables + into `occ_nested_lets`. Here are the consequences @@ -682,8 +699,9 @@ Here are the consequences There are two lexical occurrences of `v`! (NB: `orUDs` adds occ_n_br together, so occ_n_br=1 is impossible, too.) -* In the tricky (P3) we'll get an `andUDs` of - * OneOcc{occ_n_br=0} from the occurrences of `j`) +* In the tricky (P3), when analysing `case (f v) of ...`, we'll get + an `andUDs` of + * OneOcc{occ_n_br=0} from the occurrences of `j` * OneOcc{occ_n_br=1} from the (f v) These are `andUDs` together in `addOccInfo`, and hence `v` gets ManyOccs, just as it should. Clever! @@ -739,7 +757,7 @@ Wrinkles (W1) and (W2) are very similar to Note [Binder swap] (BS3). will use only one of them. So again, we can use `combineJoinPointUDs` to combine usage info from all these alternatives RHSs. -(W5) Other things being equal, we want keep the OccInfoEnv in the range of +(W5) Other things being equal, we want keep the OccInfoEnv stored in `occ_join_points` as small as possible, because it is /duplicated/ at /every occurrence/ of the join point. We really only want to include OccInfo for @@ -759,9 +777,10 @@ Wrinkles (W1) and (W2) are very similar to Note [Binder swap] (BS3). not `x` (lambda bound) nor `z` (occurs many times). To exploit this: - * `occ_local_lets` tracks which Ids are local, non-recursive lets + * `occ_nested_lets` tracks which Ids are + nested (not-top-level), non-recursive lets * `addJoinPoint` only populates j's entry with occ-info for the "tracked Ids" - of `j`; that is, that are (a) in occ_local_lets and (b) have OneOcc. + of `j`; that is, that are (a) in occ_nested_lets and (b) have OneOcc. * `combineJoinPointUDs` uses orLocalOcc for local-let Ids andLocalOcc for non-local-let Ids @@ -2913,7 +2932,7 @@ data OccEnv -- See Note [Occurrence analysis for join points] , occ_join_points :: !JoinPointInfo - , occ_local_lets :: IdSet -- Non-top-level non-rec-bound lets + , occ_nested_lets :: IdSet -- Non-top-level, non-rec-bound lets -- I tried making this field strict, but -- doing so slightly increased allocation } @@ -2968,7 +2987,7 @@ initOccEnv , occ_join_points = emptyVarEnv , occ_bs_env = emptyVarEnv , occ_bs_rng = emptyVarSet - , occ_local_lets = emptyVarSet } + , occ_nested_lets = emptyVarSet } noBinderSwaps :: OccEnv -> Bool noBinderSwaps (OccEnv { occ_bs_env = bs_env }) = isEmptyVarEnv bs_env @@ -3209,19 +3228,19 @@ postprocess_uds bndrs bad_joins uds | otherwise = env addLocalLet :: OccEnv -> TopLevelFlag -> Id -> OccEnv -addLocalLet env@(OccEnv { occ_local_lets = ids }) top_lvl id +addLocalLet env@(OccEnv { occ_nested_lets = ids }) top_lvl id | isTopLevel top_lvl = env - | otherwise = env { occ_local_lets = ids `extendVarSet` id } + | otherwise = env { occ_nested_lets = ids `extendVarSet` id } addJoinPoint :: OccEnv -> Id -> UsageDetails -> OccEnv -addJoinPoint env@(OccEnv { occ_join_points = join_points, occ_local_lets = local_lets }) +addJoinPoint env@(OccEnv { occ_join_points = join_points, occ_nested_lets = nested_lets }) join_bndr (UD { ud_env = rhs_occs }) | isEmptyVarEnv zeroed_form = env | otherwise = env { occ_join_points = extendVarEnv join_points join_bndr zeroed_form } where - zeroed_form = mapMaybeUniqSetToUFM do_one local_lets + zeroed_form = mapMaybeUniqSetToUFM do_one nested_lets -- See Note [Occurrence analysis for join points] for "zeroed form" do_one :: Var -> Maybe LocalOcc @@ -3748,12 +3767,12 @@ orUDs = combineUsageDetailsWith (\_uniq -> orLocalOcc) combineJoinPointUDs :: OccEnv -> UsageDetails -> UsageDetails -> UsageDetails -- See (W5) in Note [Occurrence analysis for join points] -combineJoinPointUDs (OccEnv { occ_local_lets = local_lets }) uds1 uds2 +combineJoinPointUDs (OccEnv { occ_nested_lets = nested_lets }) uds1 uds2 = combineUsageDetailsWith combine uds1 uds2 where combine uniq occ1 occ2 - | uniq `elemVarSetByKey` local_lets = orLocalOcc occ1 occ2 - | otherwise = andLocalOcc occ1 occ2 + | uniq `elemVarSetByKey` nested_lets = orLocalOcc occ1 occ2 + | otherwise = andLocalOcc occ1 occ2 mkOneOcc :: OccEnv -> Id -> InterestingCxt -> JoinArity -> UsageDetails mkOneOcc !env id int_cxt arity ===================================== compiler/GHC/Core/Opt/Simplify/Iteration.hs ===================================== @@ -4595,21 +4595,13 @@ mkLetUnfolding :: SimplEnv -> TopLevelFlag -> UnfoldingSource -> InId -> Bool -- True <=> this is a join point -> OutExpr -> SimplM Unfolding mkLetUnfolding env top_lvl src id is_join new_rhs --- | is_join --- , UnfNever <- guidance --- = -- For large join points, don't keep an unfolding at all if it is large --- -- This is just an attempt to keep residency under control in --- -- deeply-nested join-point such as those arising in #26425 --- return NoUnfolding - - | otherwise - = return (mkCoreUnfolding src is_top_lvl new_rhs Nothing guidance) - -- We make an unfolding *even for loop-breakers*. - -- Reason: (a) It might be useful to know that they are WHNF - -- (b) In GHC.Iface.Tidy we currently assume that, if we want to - -- expose the unfolding then indeed we *have* an unfolding - -- to expose. (We could instead use the RHS, but currently - -- we don't.) The simple thing is always to have one. + = return (mkUnfolding uf_opts src is_top_lvl is_bottoming is_join new_rhs Nothing) + -- We make an unfolding *even for loop-breakers*. + -- Reason: (a) It might be useful to know that they are WHNF + -- (b) In GHC.Iface.Tidy we currently assume that, if we want to + -- expose the unfolding then indeed we *have* an unfolding + -- to expose. (We could instead use the RHS, but currently + -- we don't.) The simple thing is always to have one. where -- !opts: otherwise, we end up retaining all the SimpleEnv !uf_opts = seUnfoldingOpts env @@ -4620,9 +4612,6 @@ mkLetUnfolding env top_lvl src id is_join new_rhs -- See Note [Force bottoming field] !is_bottoming = isDeadEndId id - is_top_bottoming = is_top_lvl && is_bottoming - guidance = calcUnfoldingGuidance uf_opts is_top_bottoming is_join new_rhs - ------------------- simplStableUnfolding :: SimplEnv -> BindContext -> InId View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/fcc38ef7a460f92e4d785bb845524ea… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/fcc38ef7a460f92e4d785bb845524ea… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/bytecode-library-combined] 15 commits: Preserve user-written kinds in data declarations
by Matthew Pickering (＠mpickering) 12 Nov '25

12 Nov '25

Matthew Pickering pushed to branch wip/bytecode-library-combined at Glasgow Haskell Compiler / GHC Commits: 3c2f4bb4 by sheaf at 2025-11-11T11:47:28-05:00 Preserve user-written kinds in data declarations This commit ensures that we preserve the user-written kind for data declarations, e.g. in type T2T = Type -> Type type D :: T2T data D a where { .. } that we preserve the user-written kind of D as 'T2T', instead of expanding the type synonym 'T2T' during kind checking. We do this by storing 'tyConKind' separately from 'tyConResKind'. This means that 'tyConKind' is not necessarily equal to 'mkTyConKind binders res_kind', as e.g. in the above example the former is 'T2T' while the latter is 'Type -> Type'. This is explained in Note [Preserve user-written TyCon kind] in GHC.Core.TyCon. This is particularly important for Haddock, as the kinds stored in interface files affect the generated documentation, and we want to preserve the user-written types as much as possible. - - - - - 19859584 by sheaf at 2025-11-11T11:47:28-05:00 Store user-written datacon tvs in interface files This commit ensures we store the user-written quantified type variables of data constructors in interface files, e.g. in data D a where MkD1 :: forall x. x -> D x MkD2 :: forall u v. u -> v -> D v The previous behaviour was to rename the universal variables to match the universal variables of the data constructor. This was undesirable because the names that end up in interface files end up mattering for generated Haddock documentation; it's better to preserve the user-written type variables. Moreover, the universal variables may not have been user-written at all, e.g. in an example such as: type T2T = Type -> Type data G :: T2T where MkG :: forall x. D x Here GHC will invent the type variable name 'a' for the first binder of the TyCon G. We really don't want to then rename the user-written 'x' into the generated 'a'. - - - - - 034b2056 by sheaf at 2025-11-11T11:47:28-05:00 DataCon univ_tvs names: pick TyCon over inferred This commit changes how we compute the names of universal type variables in GADT data constructors. This augments the existing logic that chose which type variable name to use, in GHC.Tc.TyCl.mkGADTVars. We continue to prefer DataCon tv names for user-written binders, but we now prefer TyCon tv names for inferred (non-user-written) DataCon binders. This makes a difference in examples such as: type (:~~:) :: k1 -> k2 -> Type data a :~~: b where HRefl :: a :~~: a Before this patch, we ended up giving HRefl the type: forall {k2}. forall (a :: k2). a :~~: a whereas we now give it the type: forall {k1}. forall (a :: k1). a :~~: a The important part isn't really 'k1' or 'k2', but more that the inferred type variable names of the DataCon can be arbitrary/unpredictable (as they are chosen by GHC and depend on how unification proceeds), so it's much better to use the more predictable TyCon type variable names. - - - - - 95078d00 by sheaf at 2025-11-11T11:47:28-05:00 Backpack Rename: use explicit record construction This commit updates the Backpack boilerplate in GHC.Iface.Rename to use explicit record construction rather than record update. This makes sure that the code stays up to date when the underlying constructors change (e.g. new fields are added). The rationale is further explained in Note [Prefer explicit record construction]. - - - - - 2bf36263 by sheaf at 2025-11-11T11:47:28-05:00 Store # eta binders in TyCon and use for Haddock This commit stores the number of TyCon binders that were introduced by eta-expansion (by the function GHC.Tc.Gen.HsType.splitTyConKind). This is then used to pretty-print the TyCon as the user wrote it, e.g. for type Effect :: (Type -> Type) -> Type -> Type data State s :: Effect where {..} -- arity 3 GHC will eta-expand the data declaration to data State s a b where {..} but also store in the 'TyCon' that the number of binders introduced by this eta expansion is 2. This allows us, in 'Haddock.Convert.synifyTyConKindSig', to recover the original user-written syntax, preserving the user's intent in Haddock documentation. See Note [Inline kind signatures with GADTSyntax] in Haddock.Convert. - - - - - 6c91582f by Matthew Pickering at 2025-11-11T11:48:12-05:00 driver: Properly handle errors during LinkNode steps Previously we were not properly catching errors during the LinkNode step (see T9930fail test). This is fixed by wrapping the `LinkNode` action in `wrapAction`, the same handler which is used for module compilation. Fixes #26496 - - - - - e1e1eb32 by Matthew Pickering at 2025-11-11T11:48:54-05:00 driver: Remove unecessary call to hscInsertHPT This call was left-over from e9445c013fbccf9318739ca3d095a3e0a2e1be8a If you follow the functions which call `upsweep_mod`, they immediately add the interface to the HomePackageTable when `upsweep_mod` returns. - - - - - b22777d4 by ARATA Mizuki at 2025-11-11T11:49:44-05:00 LLVM backend: Pass the +evex512 attribute to LLVM 18+ if -mavx512f is set The newer LLVM requires the +evex512 attribute to enable use of ZMM registers. LLVM exhibits a backward-compatible behavior if the cpu is `x86-64`, but not if `penryn`. Therefore, on macOS, where the cpu is set to `penryn`, we need to explicitly pass +evex512. Fixes #26410 - - - - - 6ead7d06 by Vladislav Zavialov at 2025-11-11T11:50:26-05:00 Comments only in GHC.Parser.PostProcess.Haddock Remove outdated Note [Register keyword location], as the issue it describes was addressed by commit 05eb50dff2fcc78d025e77b9418ddb369db49b9f. - - - - - 43fa8be8 by sheaf at 2025-11-11T11:51:18-05:00 localRegistersConflict: account for assignment LHS This commit fixes a serious oversight in GHC.Cmm.Sink.conflicts, specifically the code that computes which local registers conflict between an assignment and a Cmm statement. If we have: assignment: <local_reg> = <expr> node: <local_reg> = <other_expr> then clearly the two conflict, because we cannot move one statement past the other, as they assign two different values to the same local register. (Recall that 'conflicts (local_reg,expr) node' is False if and only if the assignment 'local_reg = expr' can be safely commuted past the statement 'node'.) The fix is to update 'GHC.Cmm.Sink.localRegistersConflict' to take into account the following two situations: (1) 'node' defines the LHS local register of the assignment, (2) 'node' defines a local register used in the RHS of the assignment. The bug is precisely that we were previously missing condition (1). Fixes #26550 - - - - - 79dfcfe0 by sheaf at 2025-11-11T11:51:18-05:00 Update assigned register format when spilling When we come to spilling a register to put new data into it, in GHC.CmmToAsm.Reg.Linear.allocRegsAndSpill_spill, we need to: 1. Spill the data currently in the register. That is, do a spill with a format that matches what's currently in the register. 2. Update the register assignment, allocating a virtual register to this real register, but crucially **updating the format** of this assignment. Due to shadowing in the Haskell code for allocRegsAndSpill_spill, we were mistakenly re-using the old format. This could lead to a situation where: a. We were using xmm6 to store a Double#. b. We want to store a DoubleX2# into xmm6, so we spill the current content of xmm6 to the stack using a scalar move (correct). c. We update the register assignment, but we fail to update the format of the assignment, so we continue to think that xmm6 stores a Double# and not a DoubleX2#. d. Later on, we need to spill xmm6 because it is getting clobbered by another instruction. We then decide to only spill the lower 64 bits of the register, because we still think that xmm6 only stores a Double# and not a DoubleX2#. Fixes #26542 - - - - - aada5db9 by ARATA Mizuki at 2025-11-11T11:52:07-05:00 Fix the order of spill/reload instructions The AArch64 NCG could emit multiple instructions for a single spill/reload, but their order was not consistent between the definition and a use. Fixes #26537 Co-authored-by: sheaf <sam.derbyshire(a)gmail.com> - - - - - 64ec82ff by Andreas Klebinger at 2025-11-11T11:52:48-05:00 Add hpc to release script - - - - - 531c32e3 by Matthew Pickering at 2025-11-11T17:39:10+00:00 Add support for building bytecode libraries A bytecode library is a collection of bytecode files (.gbc) and a library which combines together additional object files. A bytecode library is created by invoking GHC with the `-bytecodelib` flag. A library can be created from in-memory `ModuleByteCode` linkables or by passing `.gbc` files as arguments on the command line. Fixes #26298 - - - - - 5dac1719 by Matthew Pickering at 2025-11-11T17:39:10+00:00 Load bytecode libraries to satisfy package dependencies This commit allows you to use a bytecode library to satisfy a package dependency when using the interpreter. If a user enables `-fprefer-byte-code`, then if a package provides a bytecode library, that will be loaded and used to satisfy the dependency. The main change is to separate the relevant parts of the `LoaderState` into external and home package byte code. Bytecode is loaded into either the home package or external part (similar to HPT/EPS split), HPT bytecode can be unloaded. External bytecode is never unloaded. The unload function has also only been called with an empty list of "stable linkables" for a long time. It has been modified to directly implement a complete unloading of the home package bytecode linkables. At the moment, the bytecode libraries are found in the "library-dirs" field from the package description. In the future when `Cabal` implements support for "bytecode-library-dirs" field, we can read the bytecode libraries from there. No changes to the Cabal submodule are necessary at the moment. Four new tests are added in testsuite/tests/cabal, which generate fake package descriptions and test loading the libraries into GHCi. Fixes #26298 - - - - - 123 changed files: - .gitlab/rel_eng/upload_ghc_libs.py - compiler/GHC/Builtin/Types.hs - compiler/GHC/Builtin/Types/Literals.hs - compiler/GHC/ByteCode/Linker.hs - compiler/GHC/ByteCode/Serialize.hs - compiler/GHC/Cmm/Sink.hs - compiler/GHC/CmmToAsm/Reg/Linear.hs - compiler/GHC/CmmToAsm/Reg/Liveness.hs - compiler/GHC/Core/TyCon.hs - compiler/GHC/Core/Type.hs - compiler/GHC/Driver/Backpack.hs - compiler/GHC/Driver/Downsweep.hs - compiler/GHC/Driver/DynFlags.hs - compiler/GHC/Driver/Errors/Ppr.hs - compiler/GHC/Driver/Errors/Types.hs - compiler/GHC/Driver/Make.hs - compiler/GHC/Driver/Phases.hs - compiler/GHC/Driver/Pipeline.hs - compiler/GHC/Driver/Pipeline/Execute.hs - compiler/GHC/Driver/Session.hs - compiler/GHC/Iface/Decl.hs - compiler/GHC/Iface/Rename.hs - compiler/GHC/Iface/Syntax.hs - compiler/GHC/IfaceToCore.hs - + compiler/GHC/Linker/ByteCode.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Linker/Types.hs - compiler/GHC/Parser/PostProcess/Haddock.hs - compiler/GHC/Runtime/Debugger.hs - compiler/GHC/Runtime/Eval.hs - compiler/GHC/Settings.hs - compiler/GHC/Tc/Gen/HsType.hs - compiler/GHC/Tc/TyCl.hs - compiler/GHC/Tc/TyCl/Build.hs - compiler/GHC/Tc/TyCl/Instance.hs - compiler/GHC/Types/Error/Codes.hs - compiler/GHC/Unit/Home/PackageTable.hs - compiler/GHC/Unit/Info.hs - compiler/GHC/Unit/State.hs - compiler/ghc.cabal.in - docs/users_guide/phases.rst - libraries/ghc-boot/GHC/Unit/Database.hs - testsuite/config/ghc - testsuite/mk/boilerplate.mk - testsuite/tests/backpack/should_fail/T19244a.stderr - + testsuite/tests/cabal/Bytecode.hs - + testsuite/tests/cabal/BytecodeForeign.c - + testsuite/tests/cabal/BytecodeForeign.hs - testsuite/tests/cabal/Makefile - testsuite/tests/cabal/all.T - + testsuite/tests/cabal/bytecode.pkg - + testsuite/tests/cabal/bytecode.script - + testsuite/tests/cabal/bytecode_foreign.pkg - + testsuite/tests/cabal/bytecode_foreign.script - testsuite/tests/cabal/ghcpkg03.stderr - testsuite/tests/cabal/ghcpkg05.stderr - + testsuite/tests/cabal/pkg_bytecode.stdout - + testsuite/tests/cabal/pkg_bytecode_foreign.stdout - + testsuite/tests/cabal/pkg_bytecode_with_gbc.stderr - + testsuite/tests/cabal/pkg_bytecode_with_gbc.stdout - + testsuite/tests/cabal/pkg_bytecode_with_o.stdout - + testsuite/tests/codeGen/should_run/T26537.hs - + testsuite/tests/codeGen/should_run/T26537.stdout - testsuite/tests/codeGen/should_run/all.T - testsuite/tests/dependent/should_fail/T11334b.stderr - testsuite/tests/driver/bytecode-object/Makefile - testsuite/tests/driver/bytecode-object/all.T - testsuite/tests/driver/bytecode-object/bytecode_object19.stdout - + testsuite/tests/driver/bytecode-object/bytecode_object20.stdout - + testsuite/tests/driver/bytecode-object/bytecode_object21.stderr - + testsuite/tests/driver/bytecode-object/bytecode_object21.stdout - + testsuite/tests/driver/bytecode-object/bytecode_object23.stdout - + testsuite/tests/driver/bytecode-object/bytecode_object24.stdout - testsuite/tests/generics/T10604/T10604_deriving.stderr - testsuite/tests/ghc-e/should_fail/T9930fail.stderr - testsuite/tests/ghc-e/should_fail/all.T - testsuite/tests/ghci.debugger/scripts/print012.stdout - testsuite/tests/ghci/scripts/T10321.stdout - testsuite/tests/ghci/scripts/T24459.stdout - testsuite/tests/ghci/scripts/T7730.stdout - testsuite/tests/ghci/scripts/ghci065.stdout - testsuite/tests/haddock/should_compile_flag_haddock/T17544_kw.hs - testsuite/tests/haddock/should_compile_flag_haddock/T17544_kw.stderr - testsuite/tests/interface-stability/base-exports.stdout - testsuite/tests/interface-stability/base-exports.stdout-javascript-unknown-ghcjs - testsuite/tests/interface-stability/base-exports.stdout-mingw32 - testsuite/tests/interface-stability/base-exports.stdout-ws-32 - testsuite/tests/rename/should_fail/rnfail055.stderr - testsuite/tests/saks/should_compile/saks023.stdout - testsuite/tests/saks/should_compile/saks034.stdout - testsuite/tests/saks/should_compile/saks035.stdout - testsuite/tests/showIface/Makefile - + testsuite/tests/showIface/T26246a.hs - + testsuite/tests/showIface/T26246a.stdout - testsuite/tests/showIface/all.T - + testsuite/tests/simd/should_run/T26410_ffi.hs - + testsuite/tests/simd/should_run/T26410_ffi.stdout - + testsuite/tests/simd/should_run/T26410_ffi_c.c - + testsuite/tests/simd/should_run/T26410_prim.hs - + testsuite/tests/simd/should_run/T26410_prim.stdout - + testsuite/tests/simd/should_run/T26542.hs - + testsuite/tests/simd/should_run/T26542.stdout - + testsuite/tests/simd/should_run/T26550.hs - + testsuite/tests/simd/should_run/T26550.stdout - testsuite/tests/simd/should_run/all.T - testsuite/tests/typecheck/T16127/T16127.stderr - testsuite/tests/typecheck/should_compile/T22560d.stdout - testsuite/tests/typecheck/should_fail/T15629.stderr - utils/ghc-pkg/Main.hs - utils/haddock/haddock-api/src/Haddock/Convert.hs - utils/haddock/html-test/ref/Bug1004.html - utils/haddock/html-test/ref/Bug1050.html - + utils/haddock/html-test/ref/Bug26246.html - utils/haddock/html-test/ref/Bug85.html - utils/haddock/html-test/ref/Bug923.html - utils/haddock/html-test/ref/BundledPatterns.html - utils/haddock/html-test/ref/BundledPatterns2.html - utils/haddock/html-test/ref/ConstructorPatternExport.html - utils/haddock/html-test/ref/GADTRecords.html - utils/haddock/html-test/ref/LinearTypes.html - utils/haddock/html-test/ref/PromotedTypes.html - + utils/haddock/html-test/src/Bug26246.hs - utils/haddock/latex-test/ref/LinearTypes/LinearTypes.tex The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/37ffcd144c46e541ac2581b0fdc7f8… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/37ffcd144c46e541ac2581b0fdc7f8… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 15 commits: Preserve user-written kinds in data declarations
by Marge Bot (＠marge-bot) 12 Nov '25

12 Nov '25

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC Commits: 3c2f4bb4 by sheaf at 2025-11-11T11:47:28-05:00 Preserve user-written kinds in data declarations This commit ensures that we preserve the user-written kind for data declarations, e.g. in type T2T = Type -> Type type D :: T2T data D a where { .. } that we preserve the user-written kind of D as 'T2T', instead of expanding the type synonym 'T2T' during kind checking. We do this by storing 'tyConKind' separately from 'tyConResKind'. This means that 'tyConKind' is not necessarily equal to 'mkTyConKind binders res_kind', as e.g. in the above example the former is 'T2T' while the latter is 'Type -> Type'. This is explained in Note [Preserve user-written TyCon kind] in GHC.Core.TyCon. This is particularly important for Haddock, as the kinds stored in interface files affect the generated documentation, and we want to preserve the user-written types as much as possible. - - - - - 19859584 by sheaf at 2025-11-11T11:47:28-05:00 Store user-written datacon tvs in interface files This commit ensures we store the user-written quantified type variables of data constructors in interface files, e.g. in data D a where MkD1 :: forall x. x -> D x MkD2 :: forall u v. u -> v -> D v The previous behaviour was to rename the universal variables to match the universal variables of the data constructor. This was undesirable because the names that end up in interface files end up mattering for generated Haddock documentation; it's better to preserve the user-written type variables. Moreover, the universal variables may not have been user-written at all, e.g. in an example such as: type T2T = Type -> Type data G :: T2T where MkG :: forall x. D x Here GHC will invent the type variable name 'a' for the first binder of the TyCon G. We really don't want to then rename the user-written 'x' into the generated 'a'. - - - - - 034b2056 by sheaf at 2025-11-11T11:47:28-05:00 DataCon univ_tvs names: pick TyCon over inferred This commit changes how we compute the names of universal type variables in GADT data constructors. This augments the existing logic that chose which type variable name to use, in GHC.Tc.TyCl.mkGADTVars. We continue to prefer DataCon tv names for user-written binders, but we now prefer TyCon tv names for inferred (non-user-written) DataCon binders. This makes a difference in examples such as: type (:~~:) :: k1 -> k2 -> Type data a :~~: b where HRefl :: a :~~: a Before this patch, we ended up giving HRefl the type: forall {k2}. forall (a :: k2). a :~~: a whereas we now give it the type: forall {k1}. forall (a :: k1). a :~~: a The important part isn't really 'k1' or 'k2', but more that the inferred type variable names of the DataCon can be arbitrary/unpredictable (as they are chosen by GHC and depend on how unification proceeds), so it's much better to use the more predictable TyCon type variable names. - - - - - 95078d00 by sheaf at 2025-11-11T11:47:28-05:00 Backpack Rename: use explicit record construction This commit updates the Backpack boilerplate in GHC.Iface.Rename to use explicit record construction rather than record update. This makes sure that the code stays up to date when the underlying constructors change (e.g. new fields are added). The rationale is further explained in Note [Prefer explicit record construction]. - - - - - 2bf36263 by sheaf at 2025-11-11T11:47:28-05:00 Store # eta binders in TyCon and use for Haddock This commit stores the number of TyCon binders that were introduced by eta-expansion (by the function GHC.Tc.Gen.HsType.splitTyConKind). This is then used to pretty-print the TyCon as the user wrote it, e.g. for type Effect :: (Type -> Type) -> Type -> Type data State s :: Effect where {..} -- arity 3 GHC will eta-expand the data declaration to data State s a b where {..} but also store in the 'TyCon' that the number of binders introduced by this eta expansion is 2. This allows us, in 'Haddock.Convert.synifyTyConKindSig', to recover the original user-written syntax, preserving the user's intent in Haddock documentation. See Note [Inline kind signatures with GADTSyntax] in Haddock.Convert. - - - - - 6c91582f by Matthew Pickering at 2025-11-11T11:48:12-05:00 driver: Properly handle errors during LinkNode steps Previously we were not properly catching errors during the LinkNode step (see T9930fail test). This is fixed by wrapping the `LinkNode` action in `wrapAction`, the same handler which is used for module compilation. Fixes #26496 - - - - - e1e1eb32 by Matthew Pickering at 2025-11-11T11:48:54-05:00 driver: Remove unecessary call to hscInsertHPT This call was left-over from e9445c013fbccf9318739ca3d095a3e0a2e1be8a If you follow the functions which call `upsweep_mod`, they immediately add the interface to the HomePackageTable when `upsweep_mod` returns. - - - - - b22777d4 by ARATA Mizuki at 2025-11-11T11:49:44-05:00 LLVM backend: Pass the +evex512 attribute to LLVM 18+ if -mavx512f is set The newer LLVM requires the +evex512 attribute to enable use of ZMM registers. LLVM exhibits a backward-compatible behavior if the cpu is `x86-64`, but not if `penryn`. Therefore, on macOS, where the cpu is set to `penryn`, we need to explicitly pass +evex512. Fixes #26410 - - - - - 6ead7d06 by Vladislav Zavialov at 2025-11-11T11:50:26-05:00 Comments only in GHC.Parser.PostProcess.Haddock Remove outdated Note [Register keyword location], as the issue it describes was addressed by commit 05eb50dff2fcc78d025e77b9418ddb369db49b9f. - - - - - 43fa8be8 by sheaf at 2025-11-11T11:51:18-05:00 localRegistersConflict: account for assignment LHS This commit fixes a serious oversight in GHC.Cmm.Sink.conflicts, specifically the code that computes which local registers conflict between an assignment and a Cmm statement. If we have: assignment: <local_reg> = <expr> node: <local_reg> = <other_expr> then clearly the two conflict, because we cannot move one statement past the other, as they assign two different values to the same local register. (Recall that 'conflicts (local_reg,expr) node' is False if and only if the assignment 'local_reg = expr' can be safely commuted past the statement 'node'.) The fix is to update 'GHC.Cmm.Sink.localRegistersConflict' to take into account the following two situations: (1) 'node' defines the LHS local register of the assignment, (2) 'node' defines a local register used in the RHS of the assignment. The bug is precisely that we were previously missing condition (1). Fixes #26550 - - - - - 79dfcfe0 by sheaf at 2025-11-11T11:51:18-05:00 Update assigned register format when spilling When we come to spilling a register to put new data into it, in GHC.CmmToAsm.Reg.Linear.allocRegsAndSpill_spill, we need to: 1. Spill the data currently in the register. That is, do a spill with a format that matches what's currently in the register. 2. Update the register assignment, allocating a virtual register to this real register, but crucially **updating the format** of this assignment. Due to shadowing in the Haskell code for allocRegsAndSpill_spill, we were mistakenly re-using the old format. This could lead to a situation where: a. We were using xmm6 to store a Double#. b. We want to store a DoubleX2# into xmm6, so we spill the current content of xmm6 to the stack using a scalar move (correct). c. We update the register assignment, but we fail to update the format of the assignment, so we continue to think that xmm6 stores a Double# and not a DoubleX2#. d. Later on, we need to spill xmm6 because it is getting clobbered by another instruction. We then decide to only spill the lower 64 bits of the register, because we still think that xmm6 only stores a Double# and not a DoubleX2#. Fixes #26542 - - - - - aada5db9 by ARATA Mizuki at 2025-11-11T11:52:07-05:00 Fix the order of spill/reload instructions The AArch64 NCG could emit multiple instructions for a single spill/reload, but their order was not consistent between the definition and a use. Fixes #26537 Co-authored-by: sheaf <sam.derbyshire(a)gmail.com> - - - - - 64ec82ff by Andreas Klebinger at 2025-11-11T11:52:48-05:00 Add hpc to release script - - - - - d4d67602 by Ben Gamari at 2025-11-11T12:25:10-05:00 template-haskell: Better describe getQ semantics Clarify that the state is a type-indexed map, as suggested by #26484. - - - - - 4c0b1209 by ARATA Mizuki at 2025-11-11T12:25:16-05:00 Fix incorrect markups in the User's Guide * Correct markup for C--: "C-\-" in reST * Fix internal links * Fix code highlighting * Fix inline code: Use ``code`` rather than `code` * Remove extra backslashes Fixes #16812 Co-authored-by: sheaf <sam.derbyshire(a)gmail.com> - - - - - 108 changed files: - .gitlab/rel_eng/upload_ghc_libs.py - compiler/GHC/Builtin/Types.hs - compiler/GHC/Builtin/Types/Literals.hs - compiler/GHC/Cmm/Sink.hs - compiler/GHC/CmmToAsm/Reg/Linear.hs - compiler/GHC/CmmToAsm/Reg/Liveness.hs - compiler/GHC/Core/TyCon.hs - compiler/GHC/Core/Type.hs - compiler/GHC/Driver/Make.hs - compiler/GHC/Driver/Pipeline/Execute.hs - compiler/GHC/Iface/Decl.hs - compiler/GHC/Iface/Rename.hs - compiler/GHC/Iface/Syntax.hs - compiler/GHC/IfaceToCore.hs - compiler/GHC/Parser/PostProcess/Haddock.hs - compiler/GHC/Tc/Gen/HsType.hs - compiler/GHC/Tc/TyCl.hs - compiler/GHC/Tc/TyCl/Build.hs - compiler/GHC/Tc/TyCl/Instance.hs - docs/users_guide/bugs.rst - docs/users_guide/debug-info.rst - docs/users_guide/debugging.rst - docs/users_guide/extending_ghc.rst - docs/users_guide/exts/arrows.rst - docs/users_guide/exts/derive_any_class.rst - docs/users_guide/exts/deriving_extra.rst - docs/users_guide/exts/deriving_inferred.rst - docs/users_guide/exts/deriving_strategies.rst - docs/users_guide/exts/gadt.rst - docs/users_guide/exts/generics.rst - docs/users_guide/exts/overloaded_labels.rst - docs/users_guide/exts/overloaded_strings.rst - docs/users_guide/exts/pattern_synonyms.rst - docs/users_guide/exts/poly_kinds.rst - docs/users_guide/exts/primitives.rst - docs/users_guide/exts/rank_polymorphism.rst - docs/users_guide/exts/rebindable_syntax.rst - docs/users_guide/exts/required_type_arguments.rst - docs/users_guide/exts/scoped_type_variables.rst - docs/users_guide/exts/standalone_deriving.rst - docs/users_guide/exts/template_haskell.rst - docs/users_guide/exts/tuple_sections.rst - docs/users_guide/exts/type_data.rst - docs/users_guide/exts/type_defaulting.rst - docs/users_guide/gone_wrong.rst - docs/users_guide/hints.rst - docs/users_guide/javascript.rst - docs/users_guide/phases.rst - docs/users_guide/profiling.rst - docs/users_guide/separate_compilation.rst - docs/users_guide/using.rst - docs/users_guide/wasm.rst - docs/users_guide/win32-dlls.rst - libraries/ghc-internal/src/GHC/Internal/TH/Monad.hs - testsuite/tests/backpack/should_fail/T19244a.stderr - + testsuite/tests/codeGen/should_run/T26537.hs - + testsuite/tests/codeGen/should_run/T26537.stdout - testsuite/tests/codeGen/should_run/all.T - testsuite/tests/dependent/should_fail/T11334b.stderr - testsuite/tests/generics/T10604/T10604_deriving.stderr - testsuite/tests/ghc-e/should_fail/T9930fail.stderr - testsuite/tests/ghc-e/should_fail/all.T - testsuite/tests/ghci.debugger/scripts/print012.stdout - testsuite/tests/ghci/scripts/T10321.stdout - testsuite/tests/ghci/scripts/T24459.stdout - testsuite/tests/ghci/scripts/T7730.stdout - testsuite/tests/ghci/scripts/ghci065.stdout - testsuite/tests/haddock/should_compile_flag_haddock/T17544_kw.hs - testsuite/tests/haddock/should_compile_flag_haddock/T17544_kw.stderr - testsuite/tests/interface-stability/base-exports.stdout - testsuite/tests/interface-stability/base-exports.stdout-javascript-unknown-ghcjs - testsuite/tests/interface-stability/base-exports.stdout-mingw32 - testsuite/tests/interface-stability/base-exports.stdout-ws-32 - testsuite/tests/rename/should_fail/rnfail055.stderr - testsuite/tests/saks/should_compile/saks023.stdout - testsuite/tests/saks/should_compile/saks034.stdout - testsuite/tests/saks/should_compile/saks035.stdout - testsuite/tests/showIface/Makefile - + testsuite/tests/showIface/T26246a.hs - + testsuite/tests/showIface/T26246a.stdout - testsuite/tests/showIface/all.T - + testsuite/tests/simd/should_run/T26410_ffi.hs - + testsuite/tests/simd/should_run/T26410_ffi.stdout - + testsuite/tests/simd/should_run/T26410_ffi_c.c - + testsuite/tests/simd/should_run/T26410_prim.hs - + testsuite/tests/simd/should_run/T26410_prim.stdout - + testsuite/tests/simd/should_run/T26542.hs - + testsuite/tests/simd/should_run/T26542.stdout - + testsuite/tests/simd/should_run/T26550.hs - + testsuite/tests/simd/should_run/T26550.stdout - testsuite/tests/simd/should_run/all.T - testsuite/tests/typecheck/T16127/T16127.stderr - testsuite/tests/typecheck/should_compile/T22560d.stdout - testsuite/tests/typecheck/should_fail/T15629.stderr - utils/haddock/haddock-api/src/Haddock/Convert.hs - utils/haddock/html-test/ref/Bug1004.html - utils/haddock/html-test/ref/Bug1050.html - + utils/haddock/html-test/ref/Bug26246.html - utils/haddock/html-test/ref/Bug85.html - utils/haddock/html-test/ref/Bug923.html - utils/haddock/html-test/ref/BundledPatterns.html - utils/haddock/html-test/ref/BundledPatterns2.html - utils/haddock/html-test/ref/ConstructorPatternExport.html - utils/haddock/html-test/ref/GADTRecords.html - utils/haddock/html-test/ref/LinearTypes.html - utils/haddock/html-test/ref/PromotedTypes.html - + utils/haddock/html-test/src/Bug26246.hs - utils/haddock/latex-test/ref/LinearTypes/LinearTypes.tex The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a6bbbcd54944fee7608a3c7d97482f… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/a6bbbcd54944fee7608a3c7d97482f… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][master] Add hpc to release script
by Marge Bot (＠marge-bot) 12 Nov '25

12 Nov '25

Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC Commits: 64ec82ff by Andreas Klebinger at 2025-11-11T11:52:48-05:00 Add hpc to release script - - - - - 1 changed file: - .gitlab/rel_eng/upload_ghc_libs.py Changes: ===================================== .gitlab/rel_eng/upload_ghc_libs.py ===================================== @@ -122,6 +122,7 @@ PACKAGES = { Package('ghc-compact', Path("libraries/ghc-compact"), no_prep), Package('ghc', Path("compiler"), prep_ghc), Package('ghci', Path("libraries/ghci"), no_prep), + Package('hpc', Path("libraries/hpc"), no_prep), ] } # Dict[str, Package] View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/64ec82ffa7f48399e18fcec43051d2b… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/64ec82ffa7f48399e18fcec43051d2b… You're receiving this email because of your account on gitlab.haskell.org.

1 0