- ghc-commits - Haskell.org

[Git][ghc/ghc][wip/24279] 16 commits: Preserve user-written kinds in data declarations
by Simon Peyton Jones (＠simonpj) 14 Nov '25

14 Nov '25

Simon Peyton Jones pushed to branch wip/24279 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 - - - - - 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> - - - - - a00840ea by Simon Peyton Jones at 2025-11-14T15:23:56+00:00 Make TYPE and CONSTRAINT apart again This patch finally fixes #24279. * The story started with #11715 * Then #21623 articulated a plan, which made Type and Constraint not-apart; a horrible hack but it worked. The main patch was commit 778c6adca2c995cd8a1b84394d4d5ca26b915dac Author: Simon Peyton Jones <simonpj(a)microsoft.com> Date: Wed Nov 9 10:33:22 2022 +0000 Type vs Constraint: finally nailed * #24279 reported a bug in the above big commit; this small patch fixes it commit af6932d6c068361c6ae300d52e72fbe13f8e1f18 Author: Simon Peyton Jones <simon.peytonjones(a)gmail.com> Date: Mon Jan 8 10:49:49 2024 +0000 Make TYPE and CONSTRAINT not-apart Issue #24279 showed up a bug in the logic in GHC.Core.Unify.unify_ty which is supposed to make TYPE and CONSTRAINT be not-apart. * Then !10479 implemented "unary classes". * That change in turn allows us to make Type and Constraint apart again, cleaning up the compiler and allowing a little bit more expressiveness. It fixes the original hope in #24279, namely that `Type` and `Constraint` should be distinct throughout. - - - - - 121 changed files: - .gitlab/rel_eng/upload_ghc_libs.py - compiler/GHC/Builtin/Types.hs - compiler/GHC/Builtin/Types/Literals.hs - compiler/GHC/Builtin/Types/Prim.hs - compiler/GHC/Cmm/Sink.hs - compiler/GHC/CmmToAsm/Reg/Linear.hs - compiler/GHC/CmmToAsm/Reg/Liveness.hs - compiler/GHC/Core/Coercion.hs - compiler/GHC/Core/Lint.hs - compiler/GHC/Core/RoughMap.hs - compiler/GHC/Core/TyCon.hs - compiler/GHC/Core/Type.hs - compiler/GHC/Core/Unify.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/Instance/Class.hs - compiler/GHC/Tc/TyCl.hs - compiler/GHC/Tc/TyCl/Build.hs - compiler/GHC/Tc/TyCl/Instance.hs - docs/users_guide/9.16.1-notes.rst - 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/indexed-types/should_fail/T21092.hs - − testsuite/tests/indexed-types/should_fail/T21092.stderr - testsuite/tests/indexed-types/should_fail/all.T - 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 - testsuite/tests/typecheck/should_fail/T24279.hs - − testsuite/tests/typecheck/should_fail/T24279.stderr - testsuite/tests/typecheck/should_fail/all.T - 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/ad93c1b83eeade36b4103804da30ec… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/ad93c1b83eeade36b4103804da30ec… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc] Pushed new branch wip/fix-eventlog-flush-deadlock
by Matthew Pickering (＠mpickering) 14 Nov '25

14 Nov '25

Matthew Pickering pushed new branch wip/fix-eventlog-flush-deadlock at Glasgow Haskell Compiler / GHC -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/tree/wip/fix-eventlog-flush-deadlock You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/T26425] Experimental orUDs for RHSs
by Simon Peyton Jones (＠simonpj) 14 Nov '25

14 Nov '25

Simon Peyton Jones pushed to branch wip/T26425 at Glasgow Haskell Compiler / GHC Commits: abc9be83 by Simon Peyton Jones at 2025-11-14T00:10:55+00:00 Experimental orUDs for RHSs - - - - - 1 changed file: - compiler/GHC/Core/Opt/OccurAnal.hs Changes: ===================================== compiler/GHC/Core/Opt/OccurAnal.hs ===================================== @@ -66,7 +66,6 @@ import GHC.Builtin.Names( runRWKey ) import GHC.Unit.Module( Module ) import Data.List (mapAccumL) -import Data.List.NonEmpty (NonEmpty (..)) {- ************************************************************************ @@ -1040,10 +1039,7 @@ occAnalBind !env lvl ire (NonRec bndr rhs) thing_inside combine | mb_join@(JoinPoint {}) <- idJoinPointHood bndr = -- Analyse the RHS and /then/ the body let -- Analyse the rhs first, generating rhs_uds - !(rhs_uds_s, bndr', rhs') = occAnalNonRecRhs env lvl ire mb_join bndr rhs - rhs_uds = foldl1' (combineJoinPointUDs env) - rhs_uds_s -- NB: combineJoinPointUDs. See (W4) of - -- Note [Occurrence analysis for join points] + !(rhs_uds, bndr', rhs') = occAnalNonRecRhs env lvl ire mb_join bndr rhs -- Now analyse the body, adding the join point -- into the environment with addJoinPoint @@ -1053,9 +1049,9 @@ occAnalBind !env lvl ire (NonRec bndr rhs) thing_inside combine in if isDeadOcc occ -- Drop dead code; see Note [Dead code] then WUD body_uds body - else -- pprTrace "occAnal-nonrec" (vcat [ ppr bndr <+> ppr occ - -- , text "rhs_uds" <+> ppr rhs_uds - -- , text "body_uds" <+> ppr body_uds ]) $ + else pprTrace "occAnal-nonrec" (vcat [ ppr bndr <+> ppr occ + , text "rhs_uds" <+> ppr rhs_uds + , text "body_uds" <+> ppr body_uds ]) $ WUD (combineJoinPointUDs env rhs_uds body_uds) -- Note `orUDs` (combine [NonRec (fst (tagNonRecBinder lvl occ bndr')) rhs'] body) @@ -1072,8 +1068,8 @@ occAnalBind !env lvl ire (NonRec bndr rhs) thing_inside combine -- => join arity O of Note [Join arity prediction based on joinRhsArity] (tagged_bndr, mb_join) = tagNonRecBinder lvl occ bndr - !(rhs_uds_s, final_bndr, rhs') = occAnalNonRecRhs env lvl ire mb_join tagged_bndr rhs - in WUD (foldr andUDs body_uds rhs_uds_s) -- Note `andUDs` + !(rhs_uds, final_bndr, rhs') = occAnalNonRecRhs env lvl ire mb_join tagged_bndr rhs + in WUD (rhs_uds `andUDs` body_uds) -- Note `andUDs` (combine [NonRec final_bndr rhs'] body) ----------------- @@ -1088,15 +1084,21 @@ occAnalNonRecBody env bndr thing_inside ----------------- occAnalNonRecRhs :: OccEnv -> TopLevelFlag -> ImpRuleEdges - -> JoinPointHood -> Id -> CoreExpr - -> (NonEmpty UsageDetails, Id, CoreExpr) + -> JoinPointHood -> Id -> CoreExpr + -> (UsageDetails, Id, CoreExpr) occAnalNonRecRhs !env lvl imp_rule_edges mb_join bndr rhs | null rules, null imp_rule_infos = -- Fast path for common case of no rules. This is only worth -- 0.1% perf on average, but it's also only a line or two of code - ( adj_rhs_uds :| adj_unf_uds : [], final_bndr_no_rules, final_rhs ) + ( adj_rhs_uds `orUDs` adj_unf_uds + , final_bndr_no_rules, final_rhs ) + | otherwise - = ( adj_rhs_uds :| adj_unf_uds : adj_rule_uds, final_bndr_with_rules, final_rhs ) + = ( foldl' orUDs (adj_rhs_uds `orUDs` adj_unf_uds) adj_rule_uds + , final_bndr_with_rules, final_rhs ) + + -- orUDs: Combine the RHS, (stable) unfolding, and RULES with orUDs + -- See (W4) of Note [Occurrence analysis for join points] where --------- Right hand side --------- -- For join points, set occ_encl to OccVanilla, via setTailCtxt. If we have View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/abc9be8328b3edeac5f770ab5f54175… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/abc9be8328b3edeac5f770ab5f54175… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/T23162-part2] WIP [skip ci]
by Simon Peyton Jones (＠simonpj) 13 Nov '25

13 Nov '25

Simon Peyton Jones pushed to branch wip/T23162-part2 at Glasgow Haskell Compiler / GHC Commits: 827aaf71 by Simon Peyton Jones at 2025-11-13T17:32:23+00:00 WIP [skip ci] improving the injectivity calculation - - - - - 3 changed files: - compiler/GHC/Core/FamInstEnv.hs - compiler/GHC/Core/Unify.hs - compiler/GHC/Tc/Solver/FunDeps.hs Changes: ===================================== compiler/GHC/Core/FamInstEnv.hs ===================================== @@ -611,7 +611,7 @@ injectiveBranches injectivity -- See Note [Verifying injectivity annotation], case 1. = let getInjArgs = filterByList injectivity in_scope = mkInScopeSetList (tvs1 ++ tvs2) - in case tcUnifyTyForInjectivity True in_scope rhs1 rhs2 of + in case tcUnifyTysForInjectivity True in_scope [rhs1] [rhs2] of -- True = two-way pre-unification Nothing -> InjectivityAccepted -- RHS are different, so equations are injective. ===================================== compiler/GHC/Core/Unify.hs ===================================== @@ -12,7 +12,7 @@ module GHC.Core.Unify ( -- Side-effect free unification tcUnifyTy, tcUnifyTys, tcUnifyFunDeps, tcUnifyDebugger, - tcUnifyTysFG, tcUnifyTyForInjectivity, + tcUnifyTysFG, tcUnifyTysForInjectivity, BindTvFun, BindFamFun, BindFlag(..), matchBindTv, alwaysBindTv, alwaysBindFam, dontCareBindFam, UnifyResult, UnifyResultM(..), MaybeApartReason(..), @@ -381,7 +381,7 @@ Wrinkles (ATF7) There is one other, very special case of matching where we /do/ want to bind type families in `um_fam_env`, namely in GHC.Tc.Solver.Equality, the call - to `tcUnifyTyForInjectivity False` in `improve_injective_wanted_top`. + to `tcUnifyTysForInjectivity False` in `improve_injective_wanted_top`. Consider of a match. Consider type family G6 a = r | r -> a @@ -814,25 +814,25 @@ tcUnifyFunDeps qtvs tys1 tys2 -- | Unify or match a type-family RHS with a type (possibly another type-family RHS) -- Precondition: kinds are the same -tcUnifyTyForInjectivity +tcUnifyTysForInjectivity :: AmIUnifying -- ^ True <=> do two-way unification; -- False <=> do one-way matching. -- See end of sec 5.2 from the paper -> InScopeSet -- Should include the free tyvars of both Type args - -> Type -> Type -- Types to unify + -> [Type] -> [Type] -- Types to unify -> Maybe Subst -- This algorithm is an implementation of the "Algorithm U" presented in -- the paper "Injective type families for Haskell", Figures 2 and 3. -- The code is incorporated with the standard unifier for convenience, but -- its operation should match the specification in the paper. -tcUnifyTyForInjectivity unif in_scope t1 t2 +tcUnifyTysForInjectivity unif in_scope tys1 tys2 = case tc_unify_tys alwaysBindFam alwaysBindTv unif -- Am I unifying? True -- Do injectivity checks False -- Don't check outermost kinds RespectMultiplicities rn_env emptyTvSubstEnv emptyCvSubstEnv - [t1] [t2] of + tys1 tys2 of Unifiable (tv_subst, _cv_subst) -> Just $ maybe_fix tv_subst MaybeApart _reason (tv_subst, _cv_subst) -> Just $ maybe_fix tv_subst -- We want to *succeed* in questionable cases. ===================================== compiler/GHC/Tc/Solver/FunDeps.hs ===================================== @@ -25,7 +25,7 @@ import GHC.Core.FamInstEnv import GHC.Core.Coercion import GHC.Core.Predicate( EqRel(..) ) import GHC.Core.TyCon -import GHC.Core.Unify( tcUnifyTyForInjectivity, typeListsAreApart ) +import GHC.Core.Unify( tcUnifyTysForInjectivity, typeListsAreApart ) import GHC.Core.Coercion.Axiom import GHC.Core.TyCo.Subst( elemSubst ) @@ -545,14 +545,35 @@ 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) - ; case filter relevant_branch branches of - [CoAxBranch { cab_tvs = qtvs, cab_lhs = lhs_tys }] + ; case getRelevantBranches ax work_args work_rhs of + [CoAxBranch { cab_tvs = qtvs, cab_lhs = lhs_tys }] -> return [FDEqns { fd_qtvs = qtvs , fd_eqs = zipWith Pair lhs_tys work_args }] _ -> return [] } + +getRelevantBranches ax work_args work_rhs + = go [] (fromBranches (coAxiomBranches ax)) where - relevant_branch (CoAxBranch { cab_lhs = lhs_tys, cab_rhs = rhs_ty }) - = eqnIsRelevant lhs_tys rhs_ty work_args work_rhs + work_tys = work_rhs : work_args + work_fvs = tyCoVarsOfTypes work_tys + + go preceding [] = [] + go preceding (CoAxBranch { cab_qtvs = qtvs, cab_lhs = lhs_tys, cab_rhs = rhs_ty } : rest) + | is_relevant = br : go (br:preceding) rest + | otherwise = go (br:preceding) rest + where + is_relevant = case tcUnifyTysForInjectivity True branch_fvs work_tys (rhs_ty:lhs_tys) of + Nothing -> False + Just subst -> no_match (substTy subst lhs_tys) preceding + + branch_fvs = extendVarSetList work_fvs qtvs + + no_match lhs_tys [] = True + no_match lhs_tys (CoAxBranch { cab_qtvs = qtvs1, cab_lhs = lhs_tys1 }) + = isNothing (tcUnifyTysForInjectivity False lhs_tys1 lhs_tys) + where + all_fvs = branch_fvs `extendVarSetList` qtvs1 + mkTopOpenFamEqFDs :: TyCon -> [Bool] -> [TcType] -> Xi -> TcS [FunDepEqns] -- Implements (INJFAM:Wanted/top) View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/827aaf71386a685c00ff5dcaaa97554… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/827aaf71386a685c00ff5dcaaa97554… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/T26425] 18 commits: build: Relax ghc/ghc-boot Cabal bound to 3.16
by Simon Peyton Jones (＠simonpj) 13 Nov '25

13 Nov '25

Simon Peyton Jones pushed to branch wip/T26425 at Glasgow Haskell Compiler / GHC Commits: b5508f2c by Rodrigo Mesquita at 2025-11-04T14:10:56+00:00 build: Relax ghc/ghc-boot Cabal bound to 3.16 Fixes #26202 - - - - - c5b3541f by Rodrigo Mesquita at 2025-11-04T14:10:56+00:00 cabal-reinstall: Use haddock-api +in-tree-ghc Fixes #26202 - - - - - c6d4b945 by Rodrigo Mesquita at 2025-11-04T14:10:56+00:00 cabal-reinstall: Pass --strict to Happy This is necessary to make the generated Parser build successfully This mimics Hadrian, which always passes --strict to happy. Fixes #26202 - - - - - 79df1e0e by Rodrigo Mesquita at 2025-11-04T14:10:56+00:00 genprimopcode: Require higher happy version I've bumped the happy version to forbid deprecated Happy versions which don't successfully compile. - - - - - fa5d33de by Simon Peyton Jones at 2025-11-05T08:35:40-05:00 Add a HsWrapper optimiser This MR addresses #26349, by introduceing optSubTypeHsWrapper. There is a long Note [Deep subsumption and WpSubType] in GHC.Tc.Types.Evidence that explains what is going on. - - - - - ea58cae5 by Simon Peyton Jones at 2025-11-05T08:35:40-05:00 Improve mkWpFun_FRR This commit ensures that `mkWpFun_FRR` directly produces a `FunCo` in the cases where it can. (Previously called `mkWpFun` which in turn optimised to a `FunCo`, but that made the smarts in `mkWpFun` /essential/ rather than (as they should be) optional. - - - - - 5cdcfaed by Ben Gamari at 2025-11-06T09:01:36-05:00 compiler: Exclude units with no exposed modules from unused package check Such packages cannot be "used" in the Haskell sense of the word yet are nevertheless necessary as they may provide, e.g., C object code or link flags. Fixes #24120. - - - - - 74b8397a by Brandon Chinn at 2025-11-06T09:02:19-05:00 Replace deprecated argparse.FileType - - - - - 36ddf988 by Ben Gamari at 2025-11-06T09:03:01-05:00 Bump unix submodule to 2.8.8.0 Closes #26474. - - - - - c32b3a29 by fendor at 2025-11-06T09:03:43-05:00 Fix assertion in `postStringLen` to account for \0 byte We fix the assertion to handle trailing \0 bytes in `postStringLen`. Before this change, the assertion looked like this: ASSERT(eb->begin + eb->size > eb->pos + len + 1); Let's assume some values to see why this is actually off by one: eb->begin = 0 eb->size = 1 eb->pos = 0 len = 1 then the assertion would trigger correctly: 0 + 1 > 0 + 1 + 1 => 1 > 2 => false as there is not enough space for the \0 byte (which is the trailing +1). However, if we change `eb->size = 2`, then we do have enough space for a string of length 1, but the assertion still fails: 0 + 2 > 0 + 1 + 1 => 2 > 2 => false Which causes the assertion to fail if there is exactly enough space for the string with a trailing \0 byte. Clearly, the assertion should be `>=`! If we switch around the operand, it should become more obvious that `<=` is the correct comparison: ASSERT(eb->pos + len + 1 <= eb->begin + eb->size); This is expresses more naturally that the current position plus the length of the string (and the null byte) must be smaller or equal to the overall size of the buffer. This change also is in line with the implementation in `hasRoomForEvent` and `hasRoomForVariableEvent`: ``` StgBool hasRoomForEvent(EventsBuf *eb, EventTypeNum eNum) { uint32_t size = ...; if (eb->pos + size > eb->begin + eb->size) ... ``` the check `eb->pos + size > eb->begin + eb->size` is identical to `eb->pos + size <= eb->begin + eb->size` plus a negation. - - - - - 3034a6f2 by Ben Gamari at 2025-11-06T09:04:24-05:00 Bump os-string submodule to 2.0.8 - - - - - 39567e85 by Cheng Shao at 2025-11-06T09:05:06-05:00 rts: use computed goto for instruction dispatch in the bytecode interpreter This patch uses computed goto for instruction dispatch in the bytecode interpreter. Previously instruction dispatch is done by a classic switch loop, so executing the next instruction requires two jumps: one to the start of the switch loop and another to the case block based on the instruction tag. By using computed goto, we can build a jump table consisted of code addresses indexed by the instruction tags themselves, so executing the next instruction requires only one jump, to the destination directly fetched from the jump table. Closes #12953. - - - - - 93fc7265 by sheaf at 2025-11-06T21:33:24-05:00 Correct hasFixedRuntimeRep in matchExpectedFunTys This commit fixes a bug in the representation-polymormorphism check in GHC.Tc.Utils.Unify.matchExpectedFunTys. The problem was that we put the coercion resulting from hasFixedRuntimeRep in the wrong place, leading to the Core Lint error reported in #26528. The change is that we have to be careful when using 'mkWpFun': it expects **both** the expected and actual argument types to have a syntactically fixed RuntimeRep, as explained in Note [WpFun-FRR-INVARIANT] in GHC.Tc.Types.Evidence. On the way, this patch improves some of the commentary relating to other usages of 'mkWpFun' in the compiler, in particular in the view pattern case of 'tc_pat'. No functional changes, but some stylistic changes to make the code more readable, and make it easier to understand how we are upholding the WpFun-FRR-INVARIANT. Fixes #26528 - - - - - c052c724 by Simon Peyton Jones at 2025-11-06T21:34:06-05:00 Fix a horrible shadowing bug in implicit parameters Fixes #26451. The change is in GHC.Tc.Solver.Monad.updInertDicts where we now do /not/ delete /Wanted/ implicit-parameeter constraints. This bug has been in GHC since 9.8! But it's quite hard to provoke; I contructed a tests in T26451, but it was hard to do so. - - - - - b253013e by Georgios Karachalias at 2025-11-07T17:21:57-05:00 Remove the `CoreBindings` constructor from `LinkablePart` Adjust HscRecompStatus to disallow unhydrated WholeCoreBindings from being passed as input to getLinkDeps (which would previously panic in this case). Fixes #26497 - - - - - 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) - - - - - d6a48d8a by Simon Peyton Jones at 2025-11-13T14:59:01+00:00 Add a fast-path for args=[] to occAnalApp In the common case of having not arguments, occAnalApp was doing redundant work. - - - - - 06960766 by Simon Peyton Jones at 2025-11-13T14:59:32+00:00 Fix a performance hole in the occurrence analyser As #26425 showed, the clever stuff in Note [Occurrence analysis for join points] does a lot of duplication of usage details. This patch improved matters with a little fancy footwork. It is described in the new (W5) of the same Note. Compile-time allocations go down slightly: T18282(normal) 128,465,466 125,877,688 -2.0% T18698a(normal) 208,425,826 202,141,296 -3.0% T26425(normal) 3,344,308,317 2,458,450,080 -26.5% geo. mean -0.5% minimum -26.5% maximum +0.5% Metric Decrease: T18282 T18698a T26425 - - - - - 58 changed files: - cabal.project-reinstall - compiler/GHC/Core/Coercion.hs - compiler/GHC/Core/Opt/OccurAnal.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Make.hs - compiler/GHC/Driver/Pipeline.hs - compiler/GHC/Hs/Syn/Type.hs - compiler/GHC/HsToCore/Binds.hs - compiler/GHC/HsToCore/Match.hs - compiler/GHC/Iface/Ext/Ast.hs - compiler/GHC/Linker/Deps.hs - compiler/GHC/Linker/Types.hs - compiler/GHC/Tc/Errors/Hole.hs - compiler/GHC/Tc/Gen/App.hs - compiler/GHC/Tc/Gen/Expr.hs - compiler/GHC/Tc/Gen/Head.hs - compiler/GHC/Tc/Gen/Pat.hs - compiler/GHC/Tc/Solver/Dict.hs - compiler/GHC/Tc/Solver/Monad.hs - compiler/GHC/Tc/Types/Evidence.hs - compiler/GHC/Tc/Utils/Concrete.hs - compiler/GHC/Tc/Utils/Instantiate.hs - compiler/GHC/Tc/Utils/Unify.hs - compiler/GHC/Tc/Zonk/Type.hs - compiler/GHC/Types/Unique/FM.hs - compiler/GHC/Types/Unique/Set.hs - compiler/GHC/Types/Var/Env.hs - compiler/GHC/Unit/Home/ModInfo.hs - compiler/GHC/Unit/Module/Status.hs - compiler/GHC/Unit/Module/WholeCoreBindings.hs - compiler/Setup.hs - compiler/ghc.cabal.in - docs/users_guide/compare-flags.py - libraries/base/tests/all.T - libraries/ghc-boot/Setup.hs - libraries/ghc-boot/ghc-boot.cabal.in - libraries/os-string - libraries/unix - rts/Interpreter.c - rts/eventlog/EventLog.c - rts/gen_event_types.py - rts/include/rts/Bytecodes.h - testsuite/driver/runtests.py - testsuite/driver/testlib.py - testsuite/tests/driver/T20696/all.T - + testsuite/tests/driver/T24120.hs - testsuite/tests/driver/all.T - testsuite/tests/driver/fat-iface/all.T - + testsuite/tests/rep-poly/T26528.hs - testsuite/tests/rep-poly/all.T - + testsuite/tests/simplCore/should_compile/T26349.hs - + testsuite/tests/simplCore/should_compile/T26349.stderr - testsuite/tests/simplCore/should_compile/all.T - testsuite/tests/simplCore/should_compile/rule2.stderr - testsuite/tests/splice-imports/all.T - + testsuite/tests/typecheck/should_compile/T26451.hs - testsuite/tests/typecheck/should_compile/all.T - utils/genprimopcode/genprimopcode.cabal The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/af4a33da076d8d9bb227090008ac14… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/af4a33da076d8d9bb227090008ac14… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/T26425] Try making occ_nested_lets strict
by Simon Peyton Jones (＠simonpj) 13 Nov '25

13 Nov '25

Simon Peyton Jones pushed to branch wip/T26425 at Glasgow Haskell Compiler / GHC Commits: af4a33da by Simon Peyton Jones at 2025-11-13T10:29:08+00:00 Try making occ_nested_lets strict - - - - - 1 changed file: - compiler/GHC/Core/Opt/OccurAnal.hs Changes: ===================================== compiler/GHC/Core/Opt/OccurAnal.hs ===================================== @@ -2932,7 +2932,7 @@ data OccEnv -- See Note [Occurrence analysis for join points] , occ_join_points :: !JoinPointInfo - , occ_nested_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 } View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/af4a33da076d8d9bb227090008ac14b… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/af4a33da076d8d9bb227090008ac14b… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[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