March 2026 - ghc-commits

[Git][ghc/ghc][wip/andreask/linker_fix] Remove unused var
by Andreas Klebinger (＠AndreasK) 31 Mar '26

31 Mar '26

Andreas Klebinger pushed to branch wip/andreask/linker_fix at Glasgow Haskell Compiler / GHC Commits: 924d0ca5 by Andreas Klebinger at 2026-03-31T11:30:50+00:00 Remove unused var - - - - - 1 changed file: - rts/linker/LoadArchive.c Changes: ===================================== rts/linker/LoadArchive.c ===================================== @@ -347,7 +347,6 @@ HsInt loadArchive_ (pathchar *path) int memberIdx = 0; FILE *f = NULL; size_t thisFileNameSize = (size_t) -1; /* shut up bogus GCC warning */ - int macho_misalignment = 0; DEBUG_LOG("start\n"); DEBUG_LOG("Loading archive `%" PATH_FMT "'\n", path); View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/924d0ca5f9f30371b38f1dfdc9d95ed… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/924d0ca5f9f30371b38f1dfdc9d95ed… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/ani/no-ds-flag-cache] 2 commits: Update comments
by Simon Peyton Jones (＠simonpj) 31 Mar '26

31 Mar '26

Simon Peyton Jones pushed to branch wip/ani/no-ds-flag-cache at Glasgow Haskell Compiler / GHC Commits: 80ef7754 by Simon Peyton Jones at 2026-03-31T12:12:19+01:00 Update comments - - - - - 57261072 by Simon Peyton Jones at 2026-03-31T12:12:59+01:00 Unused imports - - - - - 2 changed files: - compiler/GHC/Tc/Gen/App.hs - compiler/GHC/Tc/Utils/Unify.hs Changes: ===================================== compiler/GHC/Tc/Gen/App.hs ===================================== @@ -461,11 +461,8 @@ checkResultTy :: HsExpr GhcRn -> TcM HsWrapper checkResultTy rn_expr (tc_fun,_) _ app_res_rho (Infer inf_res) = do { ds_flag <- getDeepSubsumptionFlag_DataConHead tc_fun - -- We must deeply-instantiate data constructors - -- E.g. data T = MkT Int int - -- f = K 3 - -- We must infer f :: Int ->{many} T - -- and not f :: Int ->{one} T + -- Why the "DataConHead" bit? See (IIR5) in + -- Note [Instantiation of InferResult] in GHC.Tc.Utils.Unify. ; fillInferResult ds_flag (exprCtOrigin rn_expr) app_res_rho inf_res } checkResultTy rn_expr (tc_fun, fun_loc) inst_args app_res_rho (Check res_ty) ===================================== compiler/GHC/Tc/Utils/Unify.hs ===================================== @@ -99,13 +99,13 @@ import qualified GHC.LanguageExtensions as LangExt import GHC.Builtin.Types import GHC.Types.Name -import GHC.Types.Id( idType, isDataConId ) +import GHC.Types.Id( idType ) import GHC.Types.Var as Var import GHC.Types.Var.Set import GHC.Types.Var.Env import GHC.Types.Basic import GHC.Types.Unique.Set (nonDetEltsUniqSet) -import GHC.Types.SrcLoc (unLoc, GenLocated (..)) +import GHC.Types.SrcLoc ( GenLocated (..) ) import GHC.Utils.Misc import GHC.Utils.Outputable as Outputable @@ -1305,7 +1305,7 @@ Usually this field is `IIF_DeepRho` meaning "return a (possibly deep) rho-type". Why is this the common case? See #17173 for discussion. Here are some examples of why: -1. Consider +(IIR1) Consider f x = (*) We want to instantiate the type of (*) before returning, else we will infer the type @@ -1317,21 +1317,46 @@ of why: instantiating. This could perhaps be worked around, but it may be hard to know even when instantiation should happen. -2. Another reason. Consider +(IIR2) Another reason. Consider f :: (?x :: Int) => a -> a g y = let ?x = 3::Int in f Here want to instantiate f's type so that the ?x::Int constraint gets discharged by the enclosing implicit-parameter binding. -3. Suppose one defines plus = (+). If we instantiate lazily, we will +(IIR3) Suppose one defines plus = (+). If we instantiate lazily, we will infer plus :: forall a. Num a => a -> a -> a. However, the monomorphism restriction compels us to infer plus :: Integer -> Integer -> Integer (or similar monotype). Indeed, the only way to know whether to apply the monomorphism restriction at all is to instantiate -HOWEVER, not always! Here are places where we want `IIF_Sigma` meaning -"return a sigma-type": +(IIR4) When -XDeepSubsumption is on, we /deeply/ instantiate. Why isn't + top-instantiation enough? Answer: to accept the following program (T26225b) with + -XDeepSubsumption, we need to deeply instantiate when inferring in checkResultTy: + + f :: Int -> (forall a. a->a) + g :: Int -> Bool -> Bool + + test b = case b of + True -> f + False -> g + + If we don't deeply instantiate in the branches of the case expression, we will + try to unify the type of `f` with that of `g`, which fails. If we instead + deeply instantiate `f`, we will fill the `InferResult` with `Int -> alpha -> alpha` + which then successfully unifies with the type of `g` when we come to fill the + `InferResult` hole a second time for the second case branch. + +(IIR5) When inferring, even /without/ -XDeepSubsumption, we must deeply instantiate + the types of data constructors. E.g + data T = MkT Int int + f = MkT 3 + We must infer MkT 3 :: Int ->{mu} T (fresh mu) + and not MkT 3 :: Int ->{one} T + See Note [Typechecking data constructors] in GHC.Tc.Gen.Head + Hence the use of `getDeepSubsumptionFlag_DataConHead` in `checkResultTy`. + +HOWEVER, `ir_inst` is not always `IIF_DeepRho`! Here are places when it isn't: * IIF_Sigma: In GHC.Tc.Module.tcRnExpr, which implements GHCi's :type command, we want to return a completely uninstantiated type. @@ -1347,23 +1372,6 @@ HOWEVER, not always! Here are places where we want `IIF_Sigma` meaning but /not/ deeply instantiate (#26331). See Note [View patterns and polymorphism] in GHC.Tc.Gen.Pat. This the only place we use IIF_ShallowRho. -Why do we want to deeply instantiate, ever? Why isn't top-instantiation enough? -Answer: to accept the following program (T26225b) with -XDeepSubsumption, we -need to deeply instantiate when inferring in checkResultTy: - - f :: Int -> (forall a. a->a) - g :: Int -> Bool -> Bool - - test b = - case b of - True -> f - False -> g - -If we don't deeply instantiate in the branches of the case expression, we will -try to unify the type of 'f' with that of 'g', which fails. If we instead -deeply instantiate 'f', we will fill the 'InferResult' with 'Int -> alpha -> alpha' -which then successfully unifies with the type of 'g' when we come to fill the -'InferResult' hole a second time for the second case branch. -} {- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3418bdbadd44cd7bf8b7cb47cf912c… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/3418bdbadd44cd7bf8b7cb47cf912c… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/26002] 9 commits: Bump minimum shake version for hadrian.
by Zubin (＠wz1000) 31 Mar '26

31 Mar '26

Zubin pushed to branch wip/26002 at Glasgow Haskell Compiler / GHC Commits: d741a6cc by Andreas Klebinger at 2026-03-31T04:39:33-04:00 Bump minimum shake version for hadrian. We also add the shake version we want to stack.yaml Fixes #26884 - - - - - 5e556f9e by Vladislav Zavialov at 2026-03-31T04:40:16-04:00 Status check for the HsType~HsExpr refactoring (#25121) Add a test case to track the status of a refactoring project within GHC whose goal is to arrive at the following declaration: type HsType = HsExpr The rationale for this is to increase code reuse between the term- and type-level code in the compiler front-end (AST, parser, renamer, type checker). The status report is saved to testsuite/tests/ghc-api/T25121_status.stdout and provides useful insights into what needs to happen to make progress on the ticket. - - - - - acffb1b1 by fendor at 2026-03-31T04:41:02-04:00 Extract Binary instances to `GHC.ByteCode.Binary` - - - - - e2ea8e25 by fendor at 2026-03-31T04:41:02-04:00 Add `seqNonEmpty` for evaluating `NonEmpty a` - - - - - 048b00b7 by fendor at 2026-03-31T04:41:02-04:00 Record `LinkableUsage` instead of `Linkable` in `LoaderState` Retaining a ByteCode `Linkable` after it has been loaded retains its `UnlinkedBCO`, keeping it alive for the remainder of the program. This starts accumulating a lot of `UnlinkedBCO` and memory over time. However, the `Linkable` is merely used to later record its usage in `mkObjectUsage`, which is used for recompilation checking. However, this is incorrect, as the interface file and bytecode objects could be in different states, e.g. the interface changes, but the bytecode library hasn't changed so we don't need to recompile and vice versa. By computing a `Fingerprint` for the `ModuleByteCode`, and recording it in the `LinkableUsage`, we know precisely whether the `ByteCode` object on disk is outdated. Thus, parts of this commit just makes sure that we efficiently compute a `Fingerprint` for `ModuleByteCode` and store it in the on-disk representation of `ModuleByteCode`. We change the `LoaderState` to retain `LinkableUsage`, which is smaller representation of a `Linkable`. This allows us to free the unneeded fields of `Linkable` after linking them. We declare the following memory invariants that this commit implements: * No `LinkablePart` should be retained from `LoaderState`. * `Linkable`s should be unloaded after they have been loaded. These invariants are unfortunately tricky to automatically uphold, so we are simply documenting our assumptions for now. We introduce the `linkable-space` test which makes sure that after loading, no `DotGBC` or `UnlinkedBCO` is retained. ------------------------- Metric Increase: MultiLayerModulesTH_OneShot ------------------------- We allocate a bit more, but the peak number of bytes doesn't change. While a bit unfortunate, accepting the metric increase. We add multiple new performance measurements where we were able to observe the desired memory invariants. Further, we add regression tests to validate that the recompilation checker behaves more correct than before. - - - - - 2d1c1997 by Simon Jakobi at 2026-03-31T04:41:46-04:00 Eliminate dictionary-passing in ListMap operations Mark the ListMap helpers 'INLINABLE' so importing modules can specialise the 'TrieMap (ListMap m)' methods and avoid recursive dictionary-passing. See Note [Making ListMap operations specialisable]. Fixes #27097 - - - - - ed2c6570 by Cheng Shao at 2026-03-31T04:42:33-04:00 testsuite: fix testdir cleanup logic on Windows testdir cleanup is unreliable on Windows (#13162) and despite existing hacks in the driver, new failure mode has occurred. This patch makes it print the warning and carry on when failed to clean up a testdir, instead of reporting a spurious framework failure. See added comment for detailed explanation. - - - - - 4c274478 by Zubin Duggal at 2026-03-31T16:40:39+05:30 Use changelog.d for release notes (#26002) GHC now uses a fragment-based changelog workflow using a custom script adapted from https://codeberg.org/fgaz/changelog-d. Contributors add a file in changelog.d/ for each user-facing change. At release time, these are assembled into release notes for sphinx (in RST) format, using the tool. New hadrian `changelog` target to generate changelogs CI job to validate changelog entries for MRs unless skipped with ~"no-changelog" label Teach sphinx about ghc-mr: extlink to link to MRs Remove `ghc-package-list` from sphinx, and implement it in changelog-d instead (Fixes #26476). - - - - - 263c7ab4 by Zubin Duggal at 2026-03-31T16:40:40+05:30 Sample changelog entries - - - - - 80 changed files: - .gitlab-ci.yml - .gitlab/issue_templates/release_tracking.md - .gitlab/merge_request_templates/Default.md - + changelog.d/changelog-entries - + changelog.d/config - + changelog.d/fix-hsExprType - + changelog.d/fix-stm-catchRetry - + changelog.d/fix-unary-typeclass-default - + changelog.d/fix-windows-async-io - + changelog.d/infix-holes-types - + compiler/GHC/ByteCode/Binary.hs - + compiler/GHC/ByteCode/Recomp/Binary.hs - compiler/GHC/ByteCode/Serialize.hs - compiler/GHC/Data/TrieMap.hs - compiler/GHC/Driver/Hooks.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Pipeline.hs - compiler/GHC/Driver/Plugins.hs - compiler/GHC/HsToCore/Usage.hs - compiler/GHC/Iface/Recomp.hs - compiler/GHC/Iface/Recomp/Types.hs - compiler/GHC/Linker/ByteCode.hs - compiler/GHC/Linker/Deps.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Linker/Types.hs - compiler/GHC/Runtime/Loader.hs - compiler/GHC/Tc/Types.hs - compiler/GHC/Tc/Utils/Monad.hs - compiler/GHC/Unit/Home/ModInfo.hs - compiler/GHC/Unit/Module/Deps.hs - compiler/GHC/Unit/Module/Status.hs - compiler/GHC/Utils/Misc.hs - compiler/ghc.cabal.in - + docs/users_guide/10.2.1-notes.rst - docs/users_guide/9.16.1-notes.rst - docs/users_guide/conf.py - docs/users_guide/ghc_config.py.in - − docs/users_guide/ghc_packages.py - ghc/GHCi/Leak.hs - hadrian/hadrian.cabal - hadrian/src/CommandLine.hs - hadrian/src/Main.hs - hadrian/src/Packages.hs - + hadrian/src/Rules/Changelog.hs - hadrian/src/Rules/Documentation.hs - hadrian/src/Rules/Test.hs - hadrian/src/Settings/Default.hs - hadrian/stack.yaml - testsuite/driver/testlib.py - testsuite/mk/boilerplate.mk - + testsuite/tests/bytecode/TLinkable/BCOTemplate.hs - + testsuite/tests/bytecode/TLinkable/LinkableUsage01.stderr - + testsuite/tests/bytecode/TLinkable/LinkableUsage02.stderr - + testsuite/tests/bytecode/TLinkable/Makefile - + testsuite/tests/bytecode/TLinkable/all.T - + testsuite/tests/bytecode/TLinkable/genLinkables.sh - + testsuite/tests/bytecode/TLinkable/linkable-space.hs - + testsuite/tests/bytecode/TLinkable/linkable-space.stdout - testsuite/tests/count-deps/CountDepsAst.stdout - testsuite/tests/count-deps/CountDepsParser.stdout - testsuite/tests/driver/multipleHomeUnits/multipleHomeUnits_recomp_th.stdout - + testsuite/tests/driver/recomp022/A1.hs - + testsuite/tests/driver/recomp022/A2.hs - + testsuite/tests/driver/recomp022/A3.hs - + testsuite/tests/driver/recomp022/B.hs - + testsuite/tests/driver/recomp022/C.hs - + testsuite/tests/driver/recomp022/Makefile - + testsuite/tests/driver/recomp022/all.T - + testsuite/tests/driver/recomp022/recomp022a.stdout - + testsuite/tests/driver/recomp022/recomp022b.stdout - + testsuite/tests/ghc-api/T25121_status.hs - + testsuite/tests/ghc-api/T25121_status.stdout - testsuite/tests/ghc-api/all.T - testsuite/tests/linters/Makefile - testsuite/tests/linters/all.T - + testsuite/tests/linters/changelog-d.stdout - + utils/changelog-d/ChangelogD.hs - + utils/changelog-d/LICENSE - + utils/changelog-d/README.md - + utils/changelog-d/changelog-d.cabal The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5ce7f29af85fb5323d9578a2fe1adc… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5ce7f29af85fb5323d9578a2fe1adc… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/26002] 2 commits: Use changelog.d for release notes (#26002)
by Zubin (＠wz1000) 31 Mar '26

31 Mar '26

Zubin pushed to branch wip/26002 at Glasgow Haskell Compiler / GHC Commits: 17872bb0 by Zubin Duggal at 2026-03-31T16:15:24+05:30 Use changelog.d for release notes (#26002) GHC now uses a fragment-based changelog workflow using a custom script adapted from https://codeberg.org/fgaz/changelog-d. Contributors add a file in changelog.d/ for each user-facing change. At release time, these are assembled into release notes for sphinx (in RST) format, using the tool. New hadrian `changelog` target to generate changelogs CI job to validate changelog entries for MRs unless skipped with ~"no-changelog" label Teach sphinx about ghc-mr: extlink to link to MRs Remove `ghc-package-list` from sphinx, and implement it in changelog-d instead (Fixes #26476). - - - - - 5ce7f29a by Zubin Duggal at 2026-03-31T16:15:52+05:30 Sample changelog entries - - - - - 31 changed files: - .gitlab-ci.yml - .gitlab/issue_templates/release_tracking.md - .gitlab/merge_request_templates/Default.md - + changelog.d/changelog-entries - + changelog.d/config - + changelog.d/fix-hsExprType - + changelog.d/fix-stm-catchRetry - + changelog.d/fix-unary-typeclass-default - + changelog.d/fix-windows-async-io - + changelog.d/infix-holes-types - + docs/users_guide/10.2.1-notes.rst - docs/users_guide/9.16.1-notes.rst - docs/users_guide/conf.py - docs/users_guide/ghc_config.py.in - − docs/users_guide/ghc_packages.py - hadrian/hadrian.cabal - hadrian/src/CommandLine.hs - hadrian/src/Main.hs - hadrian/src/Packages.hs - + hadrian/src/Rules/Changelog.hs - hadrian/src/Rules/Documentation.hs - hadrian/src/Rules/Test.hs - hadrian/src/Settings/Default.hs - testsuite/mk/boilerplate.mk - testsuite/tests/linters/Makefile - testsuite/tests/linters/all.T - + testsuite/tests/linters/changelog-d.stdout - + utils/changelog-d/ChangelogD.hs - + utils/changelog-d/LICENSE - + utils/changelog-d/README.md - + utils/changelog-d/changelog-d.cabal The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4dd2e5d107e5dbd763f804ec96f446… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/4dd2e5d107e5dbd763f804ec96f446… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc] Pushed new branch wip/26002
by Zubin (＠wz1000) 31 Mar '26

31 Mar '26

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

1 0

[Git][ghc/ghc][wip/ani/no-ds-flag-cache] Fix an oversight in getDeepSubsumptionFlag
by Simon Peyton Jones (＠simonpj) 31 Mar '26

31 Mar '26

Simon Peyton Jones pushed to branch wip/ani/no-ds-flag-cache at Glasgow Haskell Compiler / GHC Commits: 3418bdba by Simon Peyton Jones at 2026-03-31T11:08:47+01:00 Fix an oversight in getDeepSubsumptionFlag - - - - - 1 changed file: - compiler/GHC/Tc/Gen/App.hs Changes: ===================================== compiler/GHC/Tc/Gen/App.hs ===================================== @@ -350,7 +350,7 @@ Unify result type /before/ typechecking the args The latter is much better. That is why we call `checkResultTy` before tcValArgs. -} --- CAUTION: Any changes to tcApp should be reflected in tcExprSigma + tcApp :: HsExpr GhcRn -> ExpRhoType -- When checking, -XDeepSubsumption <=> deeply skolemised -> TcM (HsExpr GhcTc) @@ -459,11 +459,15 @@ checkResultTy :: HsExpr GhcRn -- expose foralls, but maybe not /deeply/ instantiated -> ExpRhoType -- Expected type; this is deeply skolemised -> TcM HsWrapper -checkResultTy rn_expr _ _ app_res_rho (Infer inf_res) - = do { ds_flag <- getDeepSubsumptionFlag +checkResultTy rn_expr (tc_fun,_) _ app_res_rho (Infer inf_res) + = do { ds_flag <- getDeepSubsumptionFlag_DataConHead tc_fun + -- We must deeply-instantiate data constructors + -- E.g. data T = MkT Int int + -- f = K 3 + -- We must infer f :: Int ->{many} T + -- and not f :: Int ->{one} T ; fillInferResult ds_flag (exprCtOrigin rn_expr) app_res_rho inf_res } - checkResultTy rn_expr (tc_fun, fun_loc) inst_args app_res_rho (Check res_ty) -- Unify with expected type from the context -- See Note [Unify with expected type before typechecking arguments] View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/3418bdbadd44cd7bf8b7cb47cf912c2… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/3418bdbadd44cd7bf8b7cb47cf912c2… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/T26831] 8 commits: Infix holes in types (#11107)
by Simon Peyton Jones (＠simonpj) 31 Mar '26

31 Mar '26

Simon Peyton Jones pushed to branch wip/T26831 at Glasgow Haskell Compiler / GHC Commits: 9831385b by Vladislav Zavialov at 2026-03-27T17:22:30-04:00 Infix holes in types (#11107) This patch introduces several improvements that follow naturally from refactoring HsOpTy to represent the operator as an HsType, aligning it with the approach taken by OpApp and HsExpr. User-facing changes: 1. Infix holes (t1 `_` t2) are now permitted in types, following the precedent set by term-level expressions. Test case: T11107 2. Error messages for illegal promotion ticks are now reported at more precise source locations. Test case: T17865 Internal changes: * The definition of HsOpTy now mirrors that of OpApp: | HsOpTy (XOpTy p) (LHsType p) (LHsType p) (LHsType p) | OpApp (XOpApp p) (LHsExpr p) (LHsExpr p) (LHsExpr p) This moves us one step closer to unifying HsType and HsExpr. * Ignoring locations, the old pattern match (HsOpTy x prom lhs op rhs) is now written as (HsOpTy x lhs (HsTyVar x' prom op) rhs) but we also handle (HsOpTy x lhs (HsWildCardTy x') rhs) Constructors other than HsTyVar and HsWildCardTy never appear in the operator position. * The various definitions across the compiler have been updated to work with the new representation, drawing inspiration from the term-level pipeline where appropriate. For example, ppr_infix_ty <=> ppr_infix_expr get_tyop <=> get_op lookupTypeFixityRn <=> lookupExprFixityRn (the latter is factored out from rnExpr) Test cases: T11107 T17865 - - - - - 5b6757d7 by mangoiv at 2026-03-27T17:23:19-04:00 ci: build i386 non-validate for deb12 This is a small fix that will unlock ghcup metadata to run, i386 debian 12 was missing as a job. - - - - - cf942119 by Cheng Shao at 2026-03-30T15:24:37-04:00 ghc-boot: remove unused SizedSeq instances and functions This commit removes unused `SizedSeq` instances and functions, only keeping the bits we need for hpc tick sequence for now. - - - - - 22c5b7cc by Cheng Shao at 2026-03-30T15:24:38-04:00 ghci: remove unused GHCi.BinaryArray This patch removes the unused `GHCi.BinaryArray` module from `ghci`. Closes #27108. - - - - - 77abb4ab by Cheng Shao at 2026-03-30T15:25:21-04:00 testsuite: mark T17912 as fragile on Windows T17912 is still fragile on Windows, it sometimes unexpectedly pass in CI. This especially strains our already scarce Windows CI runner resources. Mark it as fragile on Windows for the time being. - - - - - 177c05f1 by Simon Peyton Jones at 2026-03-31T10:42:49+01:00 Refactor eta-expansion in Prep The Prep pass does eta-expansion but I found cases where it was doing bad things. So I refactored and simplified it quite a bit. In the new design * There is no distinction between `rhs` and `body`; in particular, lambdas can now appear anywhere, rather than just as the RHS of a let-binding. * This change led to a significant simplification of Prep, and a more straightforward explanation of eta-expansion. See the new Note [Eta expansion] * The consequences is that CoreToStg needs to handle naked lambdas. This is very easy; but it does need a unique supply, which forces some simple refactoring. Having a unique supply to hand is probably a good thing anyway. - - - - - cfab9a31 by Simon Peyton Jones at 2026-03-31T10:42:49+01:00 Clarify Note [Interesting dictionary arguments] Ticket #26831 ended up concluding that the code for GHC.Core.Opt.Specialise.interestingDict was good, but the commments were a bit inadequate. This commit improves the comments slightly. - - - - - fe351792 by Simon Peyton Jones at 2026-03-31T10:43:14+01:00 Make inlining a bit more eager for overloaded functions If we have f d = ... (class-op d x y) ... we should be eager to inline `f`, because that may change the higher order call (class-op d x y) into a call to a statically known function. See the discussion on #26831. Even though this does a bit /more/ inlining, compile times decrease by an average of 0.4%. Compile time changes: DsIncompleteRecSel3(normal) 431,786,104 -2.2% ManyAlternatives(normal) 670,883,768 -1.6% ManyConstructors(normal) 3,758,493,832 -2.6% GOOD MultilineStringsPerf(normal) 29,900,576 -2.8% T14052Type(ghci) 1,047,600,848 -1.2% T17836(normal) 392,852,328 -5.2% T18478(normal) 442,785,768 -1.4% T21839c(normal) 341,536,992 -14.1% GOOD T3064(normal) 174,086,152 +5.3% BAD T5631(normal) 506,867,800 +1.0% hard_hole_fits(normal) 209,530,736 -1.3% info_table_map_perf(normal) 19,523,093,184 -1.2% parsing001(normal) 377,810,528 -1.1% pmcOrPats(normal) 60,075,264 -0.5% geo. mean -0.4% minimum -14.1% maximum +5.3% Runtime changes haddock.Cabal(normal) 27,351,988,792 -0.7% haddock.base(normal) 26,997,212,560 -0.6% haddock.compiler(normal) 219,531,332,960 -1.0% Metric Decrease: ManyConstructors T17949 T21839c Metric Increase: T3064 - - - - - 56 changed files: - .gitlab/generate-ci/gen_ci.hs - .gitlab/jobs.yaml - .gitlab/rel_eng/mk-ghcup-metadata/mk_ghcup_metadata.py - compiler/GHC/Builtin/PrimOps.hs - compiler/GHC/Core/Opt/Arity.hs - compiler/GHC/Core/Opt/Specialise.hs - compiler/GHC/Core/Tidy.hs - compiler/GHC/Core/Unfold.hs - compiler/GHC/CoreToStg.hs - compiler/GHC/CoreToStg/Prep.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Hs/Type.hs - compiler/GHC/Hs/Utils.hs - compiler/GHC/HsToCore/Quote.hs - compiler/GHC/Iface/Ext/Ast.hs - compiler/GHC/Parser.y - compiler/GHC/Parser/PostProcess.hs - compiler/GHC/Rename/Expr.hs - compiler/GHC/Rename/Fixity.hs - compiler/GHC/Rename/HsType.hs - compiler/GHC/Rename/Pat.hs - compiler/GHC/Stg/Lint.hs - compiler/GHC/Tc/Gen/App.hs - compiler/GHC/Tc/Gen/HsType.hs - compiler/GHC/Tc/Gen/Pat.hs - compiler/GHC/Tc/Gen/Sig.hs - compiler/GHC/ThToHs.hs - compiler/GHC/Types/Id.hs - compiler/GHC/Types/Id/Info.hs - compiler/Language/Haskell/Syntax/Type.hs - libraries/base/tests/IO/all.T - libraries/ghc-boot/GHC/Data/SizedSeq.hs - − libraries/ghci/GHCi/BinaryArray.hs - libraries/ghci/ghci.cabal.in - testsuite/tests/arityanal/should_compile/Arity01.stderr - testsuite/tests/arityanal/should_compile/Arity05.stderr - testsuite/tests/arityanal/should_compile/Arity08.stderr - testsuite/tests/arityanal/should_compile/Arity11.stderr - testsuite/tests/arityanal/should_compile/Arity14.stderr - testsuite/tests/ghci/should_run/BinaryArray.hs - testsuite/tests/parser/should_compile/DumpParsedAst.stderr - testsuite/tests/parser/should_compile/DumpRenamedAst.stderr - testsuite/tests/parser/should_fail/T17865.stderr - + testsuite/tests/partial-sigs/should_compile/T11107.hs - + testsuite/tests/partial-sigs/should_compile/T11107.stderr - testsuite/tests/partial-sigs/should_compile/all.T - testsuite/tests/simplCore/should_compile/T15205.stderr - testsuite/tests/wasm/should_run/control-flow/LoadCmmGroup.hs - utils/check-exact/ExactPrint.hs - utils/haddock/haddock-api/src/Haddock/Backends/Hoogle.hs - utils/haddock/haddock-api/src/Haddock/Backends/LaTeX.hs - utils/haddock/haddock-api/src/Haddock/Backends/Xhtml/Decl.hs - utils/haddock/haddock-api/src/Haddock/Convert.hs - utils/haddock/haddock-api/src/Haddock/GhcUtils.hs - utils/haddock/haddock-api/src/Haddock/Interface/Rename.hs - utils/haddock/haddock-api/src/Haddock/Interface/RenameType.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/42889b1d1274b362612730b5ebac5a… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/42889b1d1274b362612730b5ebac5a… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][master] testsuite: fix testdir cleanup logic on Windows
by Marge Bot (＠marge-bot) 31 Mar '26

31 Mar '26

Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC Commits: ed2c6570 by Cheng Shao at 2026-03-31T04:42:33-04:00 testsuite: fix testdir cleanup logic on Windows testdir cleanup is unreliable on Windows (#13162) and despite existing hacks in the driver, new failure mode has occurred. This patch makes it print the warning and carry on when failed to clean up a testdir, instead of reporting a spurious framework failure. See added comment for detailed explanation. - - - - - 1 changed file: - testsuite/driver/testlib.py Changes: ===================================== testsuite/driver/testlib.py ===================================== @@ -25,7 +25,7 @@ from testglobals import config, ghc_env, default_testopts, brokens, t, \ from testutil import strip_quotes, lndir, link_or_copy_file, passed, \ failBecause, testing_metrics, residency_testing_metrics, \ stable_perf_counters, \ - PassFail, badResult, memoize, str_removeprefix + PassFail, badResult, str_warn, str_removeprefix from term_color import Color, colored import testutil from cpu_features import have_cpu_feature @@ -3459,9 +3459,20 @@ if config.msys: exception = e retries -= 1 + # Don't fail as framework error if cleanup fails here, just + # print the warning and proceed. I've seen new failure mode + # here on Windows Server 2025 and recent msys2 installation: + # fifo.lnk is created as read-only and the on_error trick + # above somehow doesn't work. + # + # For a local testsuite run, it's in %TEMP% that will be + # periodically cleaned up anyway; for CI, there's post-job + # cleanup and runner level cleanup. It's better to report + # actual job pass/failure than to waste CPU cycles to spurious + # Windows misery. if retries == 0 and testdir.exists(): - raise Exception("Unable to remove folder '%s': %s\nUnable to start current test." - % (testdir, exception)) + print(str_warn("Unable to remove folder '%s': %s\nUnable to start current test." + % (testdir, exception))) else: def cleanup() -> None: testdir = getTestOpts().testdir_raw View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/ed2c65707aacdf442edb8098a7e5cea… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/ed2c65707aacdf442edb8098a7e5cea… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][master] Eliminate dictionary-passing in ListMap operations
by Marge Bot (＠marge-bot) 31 Mar '26

31 Mar '26

Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC Commits: 2d1c1997 by Simon Jakobi at 2026-03-31T04:41:46-04:00 Eliminate dictionary-passing in ListMap operations Mark the ListMap helpers 'INLINABLE' so importing modules can specialise the 'TrieMap (ListMap m)' methods and avoid recursive dictionary-passing. See Note [Making ListMap operations specialisable]. Fixes #27097 - - - - - 1 changed file: - compiler/GHC/Data/TrieMap.hs Changes: ===================================== compiler/GHC/Data/TrieMap.hs ===================================== @@ -327,28 +327,60 @@ instance TrieMap m => Foldable (ListMap m) where instance (TrieMap m, Outputable a) => Outputable (ListMap m a) where ppr m = text "List elts" <+> ppr (foldTM (:) m []) +{- Note [Making ListMap operations specialisable] +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ +The 'TrieMap (ListMap m)' methods are thin wrappers around these helpers: + + lookupTM = lkList lookupTM + alterTM = xtList alterTM + foldTM = fdList + filterTM = ftList + mapMaybeTM = mpList + +When these methods are used from another module, the wrappers would otherwise +remain higher-order and polymorphic in the inner trie map. That leaves the +recursive loops in 'xtList', 'fdList', 'ftList', and 'mpList' calling the +inner-map operations indirectly via the 'TrieMap m' dictionary (#27097). + +Marking the helpers 'INLINABLE' exposes unfoldings to importing modules, so +the specialiser can monomorphise those loops; see Note [Specialising imported +functions] in GHC.Core.Opt.Specialise. + +Adding the 'INLINABLE' pragmas reduced compiler allocations by 2.9% in +InstanceMatching and by 2.0% in T24984. + +We mark 'lkList' too, even though it does not itself use the 'TrieMap m' +dictionary and GHC already gives it a non-dictionary-passing worker, for +consistency with the other ListMap operations. +-} + lkList :: TrieMap m => (forall b. k -> m b -> Maybe b) -> [k] -> ListMap m a -> Maybe a lkList _ [] = lm_nil lkList lk (x:xs) = lm_cons >.> lk x >=> lkList lk xs +{-# INLINABLE lkList #-} -- See Note [Making ListMap operations specialisable] xtList :: TrieMap m => (forall b. k -> XT b -> m b -> m b) -> [k] -> XT a -> ListMap m a -> ListMap m a xtList _ [] f m = m { lm_nil = f (lm_nil m) } xtList tr (x:xs) f m = m { lm_cons = lm_cons m |> tr x |>> xtList tr xs f } +{-# INLINABLE xtList #-} -- See Note [Making ListMap operations specialisable] fdList :: forall m a b. TrieMap m => (a -> b -> b) -> ListMap m a -> b -> b fdList k m = foldMaybe k (lm_nil m) . foldTM (fdList k) (lm_cons m) +{-# INLINABLE fdList #-} -- See Note [Making ListMap operations specialisable] ftList :: TrieMap m => (a -> Bool) -> ListMap m a -> ListMap m a ftList f (LM { lm_nil = mnil, lm_cons = mcons }) = LM { lm_nil = filterMaybe f mnil, lm_cons = fmap (filterTM f) mcons } +{-# INLINABLE ftList #-} -- See Note [Making ListMap operations specialisable] mpList :: TrieMap m => (a -> Maybe b) -> ListMap m a -> ListMap m b mpList f (LM { lm_nil = mnil, lm_cons = mcons }) = LM { lm_nil = mnil >>= f, lm_cons = fmap (mapMaybeTM f) mcons } +{-# INLINABLE mpList #-} -- See Note [Making ListMap operations specialisable] {- ************************************************************************ View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/2d1c199749abcf36d20015eca4ca0ce… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/2d1c199749abcf36d20015eca4ca0ce… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][master] 3 commits: Extract Binary instances to `GHC.ByteCode.Binary`
by Marge Bot (＠marge-bot) 31 Mar '26

31 Mar '26

Marge Bot pushed to branch master at Glasgow Haskell Compiler / GHC Commits: acffb1b1 by fendor at 2026-03-31T04:41:02-04:00 Extract Binary instances to `GHC.ByteCode.Binary` - - - - - e2ea8e25 by fendor at 2026-03-31T04:41:02-04:00 Add `seqNonEmpty` for evaluating `NonEmpty a` - - - - - 048b00b7 by fendor at 2026-03-31T04:41:02-04:00 Record `LinkableUsage` instead of `Linkable` in `LoaderState` Retaining a ByteCode `Linkable` after it has been loaded retains its `UnlinkedBCO`, keeping it alive for the remainder of the program. This starts accumulating a lot of `UnlinkedBCO` and memory over time. However, the `Linkable` is merely used to later record its usage in `mkObjectUsage`, which is used for recompilation checking. However, this is incorrect, as the interface file and bytecode objects could be in different states, e.g. the interface changes, but the bytecode library hasn't changed so we don't need to recompile and vice versa. By computing a `Fingerprint` for the `ModuleByteCode`, and recording it in the `LinkableUsage`, we know precisely whether the `ByteCode` object on disk is outdated. Thus, parts of this commit just makes sure that we efficiently compute a `Fingerprint` for `ModuleByteCode` and store it in the on-disk representation of `ModuleByteCode`. We change the `LoaderState` to retain `LinkableUsage`, which is smaller representation of a `Linkable`. This allows us to free the unneeded fields of `Linkable` after linking them. We declare the following memory invariants that this commit implements: * No `LinkablePart` should be retained from `LoaderState`. * `Linkable`s should be unloaded after they have been loaded. These invariants are unfortunately tricky to automatically uphold, so we are simply documenting our assumptions for now. We introduce the `linkable-space` test which makes sure that after loading, no `DotGBC` or `UnlinkedBCO` is retained. ------------------------- Metric Increase: MultiLayerModulesTH_OneShot ------------------------- We allocate a bit more, but the peak number of bytes doesn't change. While a bit unfortunate, accepting the metric increase. We add multiple new performance measurements where we were able to observe the desired memory invariants. Further, we add regression tests to validate that the recompilation checker behaves more correct than before. - - - - - 43 changed files: - + compiler/GHC/ByteCode/Binary.hs - + compiler/GHC/ByteCode/Recomp/Binary.hs - compiler/GHC/ByteCode/Serialize.hs - compiler/GHC/Driver/Hooks.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Pipeline.hs - compiler/GHC/Driver/Plugins.hs - compiler/GHC/HsToCore/Usage.hs - compiler/GHC/Iface/Recomp.hs - compiler/GHC/Iface/Recomp/Types.hs - compiler/GHC/Linker/ByteCode.hs - compiler/GHC/Linker/Deps.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Linker/Types.hs - compiler/GHC/Runtime/Loader.hs - compiler/GHC/Tc/Types.hs - compiler/GHC/Tc/Utils/Monad.hs - compiler/GHC/Unit/Home/ModInfo.hs - compiler/GHC/Unit/Module/Deps.hs - compiler/GHC/Unit/Module/Status.hs - compiler/GHC/Utils/Misc.hs - compiler/ghc.cabal.in - ghc/GHCi/Leak.hs - + testsuite/tests/bytecode/TLinkable/BCOTemplate.hs - + testsuite/tests/bytecode/TLinkable/LinkableUsage01.stderr - + testsuite/tests/bytecode/TLinkable/LinkableUsage02.stderr - + testsuite/tests/bytecode/TLinkable/Makefile - + testsuite/tests/bytecode/TLinkable/all.T - + testsuite/tests/bytecode/TLinkable/genLinkables.sh - + testsuite/tests/bytecode/TLinkable/linkable-space.hs - + testsuite/tests/bytecode/TLinkable/linkable-space.stdout - testsuite/tests/count-deps/CountDepsAst.stdout - testsuite/tests/count-deps/CountDepsParser.stdout - testsuite/tests/driver/multipleHomeUnits/multipleHomeUnits_recomp_th.stdout - + testsuite/tests/driver/recomp022/A1.hs - + testsuite/tests/driver/recomp022/A2.hs - + testsuite/tests/driver/recomp022/A3.hs - + testsuite/tests/driver/recomp022/B.hs - + testsuite/tests/driver/recomp022/C.hs - + testsuite/tests/driver/recomp022/Makefile - + testsuite/tests/driver/recomp022/all.T - + testsuite/tests/driver/recomp022/recomp022a.stdout - + testsuite/tests/driver/recomp022/recomp022b.stdout The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5e556f9e009d5b55d89b0a91f48127… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/5e556f9e009d5b55d89b0a91f48127… You're receiving this email because of your account on gitlab.haskell.org.

1 0