Zubin pushed to branch wip/10.0.1-backports at Glasgow Haskell Compiler / GHC Commits: b11f2da2 by Zubin Duggal at 2026-09-03T13:18:46+05:30 Bump Cabal submodule to 3.18.1.0 - - - - - ad7709f1 by Cheng Shao at 2026-09-03T13:18:46+05:30 rts: always use StgInt to represent cost center id Currently cost center id is modeled as `Int` and it should be `StgInt` uniformly in the RTS, hence this patch. Fixes #27524. (cherry picked from commit ab9ab8952b1ff20ed8b092ff95d6a9f8d822c033) - - - - - e2496d4f by Zubin Duggal at 2026-09-03T13:18:46+05:30 UniqueDFM: alter should preserve insertion order Before it always inserting new elements at the end. This is problematic because instances get inserted into the map with `alterF`, which can change ordering of how instances are printed with `:info` depending on the order in which we consult interfaces I expect `alter id k = id` and `alter (fmap f) k = adjust f k`. Moving keys to the end breaks that (`adjust` already preserves position). Fixes #27532 (cherry picked from commit f6f2343fbbfdfd8aaed9babf5983e3e24c08ca85) - - - - - 507f6920 by Duncan Coutts at 2026-09-03T13:18:46+05:30 Add missing updateRemembSetPushClosure in poll I/O manager For the non-moving GC. (cherry picked from commit daf2bd6f71b7ee309374dddf0d4793bbc0ed066d) - - - - - 0e505903 by Duncan Coutts at 2026-09-03T13:18:46+05:30 Eliminate STM_AWOKEN It was used as nullary closure for the block_info.closure in the case of a thread being awoken after an STM transaction. However, while it was written, it was never read, so contributed nothing to the behaviour. Furthermore, in the only place it was set (in tryWakeupThread) the why_blocked was immediately overwritten by the NotBlocked status, and the block_info was updated accordingly (by appendToRunQueue). So it didn't even serve a purpose of clarifying an intermediate state, there really was no such intermediate state. Cleaning this up will allow the BlockedOnSTM case to follow the same pattern as the other why_blocked cases that do not use the block_info, and in turn this reduces the number of different categories. (cherry picked from commit 4d798b17c9b83f280c102ca7f96047bc0ad52df1) - - - - - 11bf7aa0 by Duncan Coutts at 2026-09-03T13:18:46+05:30 Document that eventlog thread stop code ThreadBlocked is no longer used It has not been used since GHC 7.0.x (2011). In 7.2 all the BlockedOn* codes were added, and these were and are used instead of ThreadBlocked. (cherry picked from commit e1cece79a6c8e53796188acd543a8b565b18a3fb) - - - - - 8b9bb52c by Duncan Coutts at 2026-09-03T13:18:46+05:30 Add a proper mapping to eventlog external thread stop status That is the mapping from rts-internal codes, to the coes used in the status field in the eventlog EVENT_STOP_THREAD event. See issue #9003 for what goes wrong when we mess this up. In that ticket, people note that we should really not require the internal tso->why_blocked codes to leak into the external eventlog thread stop codes. The same principle applies to the StgThreadReturnCode. This change properly separates them, and explicitly maps between them using a pair of (compact, constant) tables. These tables are pretty small (with no alignment constraints) and will soon shrink so it seems a sensible tradeoff. We also introduce and use proper EVENT_STOP_THREAD constants in the event log format header. Previously there was not specification in the code for these (only in the docs): the values were encoded into the conversion code. This will allow us to renumber the internal why_blockd codes without breaking the eventlog output. (cherry picked from commit 795db1151237be5a3d0d2cdccb4c43309b587cdf) - - - - - 9d0f584a by Duncan Coutts at 2026-09-03T13:18:46+05:30 Remove unused tso->block_info.wakeup member Presumably it was used once, but not now. (cherry picked from commit 6f1c8efa1b4c78273daca99f9dda0a7e3d771330) - - - - - 74546fac by Duncan Coutts at 2026-09-03T13:18:46+05:30 Document StgTSOBlockInfo to say what cases use what members In principle, tso->why_blocked is the tag for the StgTSOBlockInfo union, so we should be able to say for each union member the why_blocked cases that use that member. (cherry picked from commit 740b88a980c4aa7f28fcf3aa89f7df8aea2813a9) - - - - - 4a8b97c1 by Duncan Coutts at 2026-09-03T13:18:46+05:30 Add a tso->block_info.mvar member and use it in preference to the generic block_info.closure union member, with casts. The plan is that when we know what case we're in (via tso->why_blocked) then we can always access the correct union member, and so we will only need to access block_info.closure for generic cases where we don't know or don't care. (cherry picked from commit 5b92eae2638db71ff8725295ec2a8ca254c0720b) - - - - - 0be9dc88 by Duncan Coutts at 2026-09-03T13:18:46+05:30 Add a tso->block_info.unused member and use it in preference to the generic block_info.closure union member, with casts. The plan is that when we know what case we're in (via tso->why_blocked) then we can always access the correct union member, and so we will only need to access block_info.closure for generic cases where we don't know or don't care. (cherry picked from commit d931715fbea83ccd402d280965a5d096a9f72949) - - - - - cb326511 by Duncan Coutts at 2026-09-03T13:18:46+05:30 Avoid storing to tso->block_info.closure In one case we can use a specific union member (.prev) instead. In several cases the stores were in fact redundant because of subsequent overwrites. In scavengeTSO we replace setting tso->block_info.closure to a valid closure, with an assertion that the block_info.unused is already set to END_TSO_QUEUE which is a valid (static) closure. (cherry picked from commit 47e28ebbb4e22ad2ddb27c3f4acc5df291276743) - - - - - 57cd71ad by Duncan Coutts at 2026-09-03T13:18:46+05:30 Renumber the tso->why_blocked constants We can do this now because we have separated the internal values from the external ones used in the eventlog. This lets us put them back into a deliberate order and consolodate some gaps. More importantly, it is a prepation for a slightly more sophisticated encoding. (cherry picked from commit 96e4749d9f9b75e99d7b860325b92a5b3704e784) - - - - - 562e4370 by Duncan Coutts at 2026-09-03T13:18:46+05:30 Define constants for the existing stg_threadStatuszh return codes The stg_threadStatuszh reuses the internal tso->why_blocked codes but also extends them with a couple previously magic values. This is awkward since we need to know what those magic values are so we don't accidentally use those values to mean something else. By pulling a definition up to where the why_blocked codes are defined we will be able to avoid mistakenly assining those codes some meaning (or just changing the BlockedThreadComplete, BlockedThreadKilled code if necessary). (cherry picked from commit 8f62661c133338100803347084de3566e325e64c) - - - - - 2adb7139 by Duncan Coutts at 2026-09-03T13:18:46+05:30 Extend the tso->why_blocked encoding to indicate block_info closures We use some bit tricks to cheaply and generically test if a tso->why_blocked tag implies that the corresponding tso->block_info will contain a non-trivial valid closure (i.e. not just block_info.unused set to END_TSO_QUEUE). In particular we arrange for most why_blocked values to naturally have a distinguishing bit, but for the BlockedOn{Read,Write,Delay} cases, they can come in either non-closure or closure forms. We allow an additional bit to distinguish these cases. The non-closure forms are only from legacy I/O managers: select and win32-legacy. So this extra bit mechanism will be able to be retired once the legacy I/O managers are themselves retired. This means in a few places we need to untag the why_blocked value before inspecting it, but in most places we do not. (cherry picked from commit 42c69ae2d58310c703abaa4ec933973fa9b136d3) - - - - - 228a625b by Duncan Coutts at 2026-09-03T13:18:46+05:30 Use BlockInfoForceNonClosure in the select I/O manager (cherry picked from commit 7c64632b46ac660fc0779ae96d9a05d11537b743) - - - - - e768d359 by Duncan Coutts at 2026-09-03T13:18:46+05:30 Use BlockInfoForceNonClosure in the win32-legacy I/O manager for the BlockedOn{Read,Write} since these use the non-heap allocated StgAsyncIOResult. (cherry picked from commit 8fd7104a0d63208f8408a7e5cd185bd2020225c8) - - - - - c6092e3d by Duncan Coutts at 2026-09-03T13:18:46+05:30 Enforce the why_blocked and block_info rules in checkTSO We now check the cases wher IsBlockInfoClosure should hold, the cases that are supposed to use block_info.unused == END_TSO_QUEUE, and which cases are allowed to use BlockInfoForceNonClosure. This partially enforces the use of why_blocked as a tag for the block_info union. We could be stricter and check for the correct expected info table for the closure cases. (cherry picked from commit e0da603b8e24cfc633f29990be9ca7008f45b3c2) - - - - - 205bce9a by Duncan Coutts at 2026-09-03T13:18:46+05:30 Use IsBlockInfoClosure to simplify several tests In GC and generic traversal we need to know if we should look at the block_info.closure or not. Now we can do just that using a cheap bit test on the why_blocked tag. This fixes issue 26717, where the problem was that some GC modes did not know when to look at block_info.closure, because the poll I/O manager uses a closure for BlockedOn{Read,Write} while the select I/O manager uses a non-closure. Now this information is in the why_blocked tag itself. (cherry picked from commit 1dd0f381ab96d3f46e113c90858870e95bd3caba) - - - - - 6fa33e9b by Duncan Coutts at 2026-09-03T13:18:46+05:30 Remove the now-unused scavengeTSOIOManager The GC no longer has to delegate to the I/O manager, since it can use IsBlockInfoClosure to decide things itself. (cherry picked from commit 7a00ffbc311e6ee53e8b1b9181e37c3795a7b884) - - - - - 0f5b227d by Duncan Coutts at 2026-09-03T13:18:46+05:30 Remove duplicate assertion (cherry picked from commit 522a481f5f1e51a8bdd0902012bdc467535a0382) - - - - - f5342612 by Duncan Coutts at 2026-09-03T13:18:46+05:30 Follow atomic access rules more consistently for tso->why_blocked The rule is this: store block_info *before* why_blocked store why_blocked using store release load why_blocked using load acquire load block_info *after* why_blocked This is a an atomic store release / load acquire pair and (if the reads are in a separate thread to the writes, and the read receives the value stored) then this guarantees a full "happens before" relationship of these stores and loads. In some cases, we do not need a full load acquire, because we don't read the block_info at all and so do not need any ordering. In this case we just need an atomic relaxed load. This was being followed in most places, but not all. If there's good reason in any case that we don't need atomic access, then we should document that in a comment. In the absence of that I think it's easier to follow the rule everywhere. (cherry picked from commit 0874d965ef1fec847561418857e63c067b91b0b7) - - - - - 733924c3 by Duncan Coutts at 2026-09-03T13:18:46+05:30 Add a changelog entry (cherry picked from commit 8f0bdbe138a2e1914cba7963b6931402f99c8710) - - - - - 54345072 by Cheng Shao at 2026-09-03T14:39:44+05:30 configure: bump LlvmMaxVersion to 23 This patch bumps `LlvmMaxVersion` to 23 to support LLVM 22.x releases. (cherry picked from commit cc9cc6d5df7fb3845b1409fe708e1097896252a7) - - - - - dd3ae55b by Cheng Shao at 2026-09-03T14:39:44+05:30 changelog: add llvm 22.x support (cherry picked from commit 2ea7ef8ef090fa44a0191271f644a0917908ef40) - - - - - b593915c by fendor at 2026-09-03T14:39:44+05:30 Drop `preloadClosure` from `UnitState` It is always hard-coded to the same value. Backpack Unit instantiation isn't using it any more. Allows us to simplify the API and get rid of `improveUnit`. (cherry picked from commit fb5246adb7e10bd9ef07de314eaf98fbcfb729a1) - - - - - 3110b6f2 by fendor at 2026-09-03T14:42:48+05:30 Introduce global unit database cache As a first step for better sharing of `UnitInfo` across `UnitEnv`, we introduce a new datatype called `ExternalUnitDatabases`. It primarily serves as an in-memory representation of *all* `UnitDatabase`s across `UnitEnv`. This means, if multiple `HomeUnitEnv`s depend on the same database, one way or another, we make sure that we don't parse from disk every time. Instead, we store the in-memory representation in `ExternalUnitDatabases`. `ExternalUnitDatabaseCache` is the equivalent of `ExternalUnitState` in the `UnitEnv`. It is a mutable variable wrapping `ExternalUnitDatabases`. The mutable `ExternalUnitDatabaseCache` is used in `initUnits` to make sure we don't parse the same unit database multiple times. Almost by accident, we change the semantics of `initUnits` to honour modifications to `packageDBFlags`. The inability to change `packageDBFlags` while also reusing the already parsed `UnitDatabase`s was reported in #26423 as a bug. Hence, we think this behaviour change is warranted and acceptable, especially since it comes with a breaking change to the `initUnits` API. Add regression test for #26423 Closes #26423 (cherry picked from commit 5d0ab71ac1d01c2ef19bf3146adb7dac8733dca5) - - - - - fcc004c0 by fendor at 2026-09-03T17:39:18+05:30 Introduce UnitIndex for global external unit caching `UnitInfo`s have been observed to cause a lot of memory usage in #27500. Especially with multiple home units, as the same (external) units are processed from scratch, even though most of the time we end up with exactly the same `UnitInfo`. We introduce a `UnitEnv` global cache that allows us to store external unit information that is used across all `HomeUnitEnv`s. The most important change in this commit is the introduction of the `UnitIndex`. It stores a global mapping of `UnitId` -> `UnitInfo`, and `initUnits` always uses the cached `UnitInfo` entry to populate each `HomeUnitEnv`'s `UnitState`. This allows us to ensure the following property:

Each `UnitInfo` should be alive exactly once in GHC.

All `UnitState`s should reference 'UnitInfo's stored in the 'UnitIndex'. This ensured by calling 'initUnits' with the 'UnitIndex'. In addition, the `ExternalUnitDatabases` may also hold a reference to each on-disk representation of `UnitInfo`. This means, we impose an hard upper bound on the number of `UnitInfo`s alive in the GHC session:

The number of alive `UnitInfo`s closure objects must be the sum of all loaded unit database times two.

We add performance regression tests that make sure the number of live `UnitInfo` cannot exceed this threshold. Closes #27500 ------------------------- Metric Decrease: MultiComponentModules MultiComponentModulesRecomp MultiComponentModulesRecomp100 mhu-perf LinkableUsage02 ------------------------- These metrics increases are especially notable, as we are not even sharing anything big but merely the global package database with 50 entries. It shows how careful sharing of `UnitInfo` can improve memory usage. We expect this to be much more notable when the whole cabal package database is shared across multiple home units. `LinkableUsage02` metric decreases on unreg and i386 platform, only. --- Technical details To share the `UnitInfo`s correctly, it is important that we extract the `WireMap` into the `UnitIndex`. At the moment of writing, `WireMap` must be globally the same for all `HomeUnitEnv`s. This is important, as we could otherwise not cache the "fully-resolved" `UnitInfo`, as we don't change the `UnitId` or `unitAbiHash` when resolving wired-in units. Thus, there could be ambiguities, when the `WireMap` is not the same for all `UnitState`s across the `UnitEnv`. We consider a `UnitInfo` fully-resolved, if wired-in units have been updated, the `UnitInfo` has been validated and variables in the unit config, such as `${pkgroot}` have been resolved. Updating the wired-in units requires the `WireMap` to be globally the same. (cherry picked from commit 6cce494a7ec43953c7a949e0d8ce712abfe73da7) - - - - - 9d0fd696 by Ben Gamari at 2026-09-03T17:39:18+05:30 base: Don't drop exception context in SomeException(toException) For reasons that are lost to time, the implementation of [CLC #200] that was merged inappropriately dropped `ExceptionContext` in the `toException` implementation given to `SomeException`. Fix this infelicity. [CLC #200]: https://github.com/haskell/core-libraries-committee/issues/200 (cherry picked from commit 2ab02c579a9625438f5281a258051cb32ba40004) - - - - - 7ccf9b9c by Vladislav Zavialov at 2026-09-03T17:39:18+05:30 Discard type arguments in tcPatToExpr (#27440, #27583) The builder expression of an implicitly bidirectional pattern synonym must not mention types written in the RHS: * Invisible type arguments led to a panic (#27440) * Required type arguments failed with out-of-scope variables (#27583) Both are now discarded, following the precedent established by pattern signatures (#9867). Discarding type arguments takes some care: a type pattern cannot be told from a value pattern by syntax alone, as the `type` keyword may be omitted. Consider: data T a b c where MkT :: forall a. forall b c -> a -> T a b c pattern P :: x -> T x y z pattern P x = MkT @a (type b) c x In P's right-hand side, `@a` and `type b` are clearly type arguments, but what about `c` and `x`? We can only tell by matching the patterns against MkT's type. So tcPatToExpr now runs in TcM and matches the arguments against the constructor's TyVarBinders using zipPatsBndrs, which is made public for this purpose. The resulting builder is $bP x = MkT _ _ x. See Note [Discarding types in the builder expression]. Test cases: T27440a T27440b T27440c T27440d T27440e T27583a T27583b T27583c T27583d T27583e T27583f T27583g Metric Increase: LinkableUsage02 Metric Decrease: T27336 Assisted-by: Claude Opus 5 (cherry picked from commit 4f98510802423dcd98fa62af77997189ee97a111) - - - - - 23e3630a by sheaf at 2026-09-03T17:39:18+05:30 mkWpFun_FRR: fix ordering of coercion composition When the subsumption machinery generates an eta-expansion, we must perform a representation polymorphism check to ensure the lambda binder it introduces has a fixed runtime representation. This is done in GHC.Tc.Utils.mkWpFun_FRR. This check involves composing quite a few coercions, arising from representation-polymorphism checks on both the actual and expected argument types. These coercions are then chained using HsWrapper composition, <.>. The ordering of composition was incorrect, leading to the Core Lint failure reported in #27639. This commit fixes that. Fixes #27639 (cherry picked from commit eb1dcd4d98548b7bc64c323dc352ddbf149a91ec) - - - - - e6e6ac3f by Bernhard M. Wiedemann at 2026-09-03T17:39:18+05:30 driver: Link object files in a deterministic order The object files handed to the linker come from the HomePackageTable, which is ordered by the order in which modules finished compiling. With -j1 that is the build plan order, with -jN it is whatever the scheduler produced, so the same sources can link to different (but equivalent) binaries. The order reaches the output: .text and .rodata contributions are concatenated in link order, so e.g. building the hdav executable of the DAV package twice, once with -j1 and once with -j4, yields two binaries that differ in ~100kB of section contents. Sort the home modules by module before collecting their linkables, guarded under `Opt_ObjectDeterminism` . Fixes #27612 Signed-off-by: Bernhard M. Wiedemann <bwiedemann@suse.de> (cherry picked from commit e8d1a0d68067ba344fdff816f6b84f0117ffdc59) - - - - - 2ce5dbb2 by Zubin Duggal at 2026-09-03T17:39:18+05:30 hadrian: Fix links to remaining doc sites to not use the package hash for haddock links In 07267f79d91169f474cacc8bcd38d76a6e97887d we changed hadrian to not include the package hash in the haddock directory. This patch takes care of a few remaining links that were missed in that patch Fixes #27671 (cherry picked from commit 1446bb039a635f2b836be19f062cbffa568fe4c5) - - - - - 8f3d32ce by Vladislav Zavialov at 2026-09-03T17:39:19+05:30 Fix tcLookupId panic with RequiredTypeArguments and PatternSynonyms (#27586) The arguments declared on the left-hand side of a pattern synonym are looked up as term variables bound by its right-hand side. Prior to this patch, that lookup panicked with RequiredTypeArguments: data T a where MkT :: forall a -> T a pattern P :: Int -> T Int pattern P x = MkT x On the RHS, `x` looks like a term argument, so the renamer binds it in the term namespace. Only during type checking does it turn out to be a type variable, so the lookup on the LHS finds an ATyVar rather than an ATcId. As the lookup was done with tcLookupId, it resulted in a panic. Now the arguments are looked up with tcLookupPatSynArg, which reports an illegal term-level use of `x`, just as an ordinary function definition `f (MkT x) = x` does. Test cases: T27586a T27586b T27586c Assisted-by: Claude Opus 5 (cherry picked from commit b757727a78613e7437a713058c24b94e10697f47) - - - - - 1b1f677a by Zubin Duggal at 2026-09-03T17:39:19+05:30 DmdAnal: Fix maxDmdType We need to eta expand the smaller DmdType using defaultArgDmd, like in lubDmdType. Introduce zipDmdType as a common combinator to implement both maxDmdType and lubDmdType uniformly. fixes #27626 (cherry picked from commit e31885816b7c597ad89b05da64b21c5a241bf674) - - - - - e7854977 by Andreas Klebinger at 2026-09-03T17:39:19+05:30 cmm dumps: Add machop width info with -dppr-debug for infix ops. (cherry picked from commit e9bbe8f924ec0b9d0772cf3d4f20aa6a25f28345) - - - - - 8c36cb1d by Andreas Klebinger at 2026-09-03T17:39:19+05:30 CmmLint: Check for unsupported MachOp widths machOpArgReps now maps MachOp + Width to a list of supported argument widths or Nothing if the given operation is not supported at the given width. This allows us to check for nonsensical combinations like FloatToInt at Word16. Similarly we now check that every address is actually wordwidth. (cherry picked from commit 86e3a9d8d0a85b5c80dad212cf3ec8fbf1ba72e6) - - - - - 6968969f by Andreas Klebinger at 2026-09-03T17:39:19+05:30 arm64 ncg: The big subword truncation fix. A set of slightly related fixes to arm subword handling: Bitmask immediates: Don't produce overflowing assembly literals. There is still another bug here that causes us to miss some valid literals but we will fix that later. Improve subword truncation handling: We now use a small set of helpers to truncate `Register` values rather than truncating immediate `Reg` values which greatly simplifies the code structure. This fixes a great many bugs to do with sign/zero extending subwords or the lack thereof. We now establish the invariant that subword values are zero-extended at every site at which they come into "scope" of the ncg, and rely on the invariant throughout rather than pessimistically inserting redundant extensions in a hodgepodge manner at the use sites of these values. This fixes at least the bugs described in issues #27533, #27430 #27537, #27538, #27539, and #27550. But likely more bugs yet not found. Subword ffi results: Apply truncations when calling functions returning subword values. genCondJump: Don't sign extend signed values in the input register as it might map to a local variable, corrupting the value stored within. Fix subword store/load instructions.: We used to read those at 32bit width even for smaller values possibly resulting in invalid memory access. Now we construct the suffix for subword variants based on the instruction format for these. (cherry picked from commit 13781cca5c24c2671d651fd2b13a561c7386fe3a) - - - - - b9079f99 by Andreas Klebinger at 2026-09-03T17:39:19+05:30 arm64 ncg: Fix MO_V_Broadcast for non-literals. We now use OpReg instead of OpScalarAsVec as required since we broadcast a gp register. Also adds a test. Fixes #27565. (cherry picked from commit d8fa5d7cc060aa7d3bee8a68b922c85b626cbe8c) - - - - - 78a79218 by Andreas Klebinger at 2026-09-03T17:39:19+05:30 Add some test cases covering bugs in the arm ncg. * Test for #27430 (subword ffi results) * #27537 - subword conversions * #27538 - subwords used in conditional * #27533 - single byte read (cherry picked from commit 94822c951c2a6f77c7766720e0d4ff7d4afb7290) - - - - - ccab2dbe by Andreas Klebinger at 2026-09-03T17:39:19+05:30 cmmLint: Lint against MO_FS_Truncate subword use. (cherry picked from commit dd1ba88a70f47bead722e9dae8e91f9a617258aa) - - - - - 2bdf5ced by Rodrigo Mesquita at 2026-09-03T17:39:19+05:30 rts: refactor to reduce THREADED_RTS in MSG_UPD_TSO_FLAGS - No behavior change in this commit (well, a small optimization here makes us do less work if the target TSO owned by the curr. capability) - Move all THREADED_RTS CPP needed into `updThreadFlag` - Merge MSG_SET_TSO_FLAGS and MSG_UNSET_TSO_FLAGS into MSG_UPD_TSO_FLAGS plus a `set` bool field in the MessageUpdTSOFlag struct Towards #27729 (cherry picked from commit bb3241717c8ee46e31fbdb3cfaed9736ba7257ea) - - - - - 030362c7 by Rodrigo Mesquita at 2026-09-03T17:39:19+05:30 rts: Fix race condition in MSG_UPD_TSO_FLAGS execution The code for processing the MSG_UPD_TSO_FLAGS message was not taking into consideration that the TSO's owner might have moved in between that capability receiving the message (since it was its previous owner) and starting to process its inbox (a point at which it was no longer the owner) Added Note [TSO owner may change in between Msg being sent and received] to explain this race and the pattern used to fix this, where we just forward the message to the new owner. Fixes #27729 (cherry picked from commit ed99b7b7bed699f3f2047672be7709c6d22b6df7) - - - - - 95aeec9e by fendor at 2026-09-03T17:39:19+05:30 GHCi: Fix order of `PackageDBFlag`s for interactive home unit `PackageDBFlag`s are stored in reverse order of cli specification. When sorting the `PackageDBFlag`s by longest common prefix, we need thus to reverse the package db stacks before calculating the prefix. We make sure to reverse the package db stack for the interactive home unit to uphold that later specified package dbs overwrite earlier ones. Resolved and adds regression test for #27640 (cherry picked from commit 06fde293f2e8c80db11f4d01fcdfc482c1128db5) - - - - - 584ad45c by fendor at 2026-09-03T17:39:19+05:30 Reuse the UnitIndexCache after initialising multiple home units (cherry picked from commit 024c4d04a98f7e27b3dcb93f9b038f9b6b5a1ad9) - - - - - b714ea9b by Andreas Klebinger at 2026-09-03T17:39:19+05:30 Specialise: Stop looping on recursive dictionaries in interestingDict interestingDict now doesn't look through loopbreaker unfoldings. Doing so would cause infinite loops on certain dictionaries. Fixes #27705. (cherry picked from commit 578bd18509f0d2aeb004231a197f7f3898f86a2a) - - - - - 6e559c09 by Simon Peyton Jones at 2026-09-03T17:39:19+05:30 Never make an absent filler for a constraint type mkAbsentFiller used isTerminatingType to decide, but that is not enough. Consider class Eq a => UC a where {} let u :: UC Int -- UC Int is a "non-terminating type" u = error "Absent" let e :: Eq Int -- Eq Int is a "terminating type" e = $p1UC u We clearly must not make a filler for `e`, because we speculatively evaluate it. But speculatively evaluating `e` forces `u`, so we must not make one for `u` either. Asking isDictTy instead is not enough either, because it does not catch a constraint hidden behind an unreduced type family application: type family F a :: Constraint type instance F W = TC W a :: F W => Int -> Int -- (F W) argument is absent Oops! Entered absent arg Arg: irred Type: F W So play safe and use isPredTy: never make an absent filler for any constraint-kinded type. Fixes #27627 (cherry picked from commit 7bf546fc423e23cb649580016ee494efbfe144ab) - - - - - 97e3de95 by Zubin Duggal at 2026-09-03T17:39:19+05:30 Add tests for absent fillers at dictionary types T27627 a unary class whose superclass is a non-unary class T27627a ...whose superclass is a Constraint-kinded type family T27627b ...whose superclass is a quantified constraint T27627c a unary class applied to itself, (UC (UC (TC a))) T27627e a (forall b. P b) dictionary that loops (cherry picked from commit 5f474953d1880232b5e6c5741f08746e28cd25ab) - - - - - 61ec7bf7 by Zubin Duggal at 2026-09-03T17:39:19+05:30 An abstract TyCon may hide a unary class A class declared in an hs-boot file is an AbstractTyCon inside the module loop, and compiling the real declaration may reveal it to be a UnaryClassTyCon. - isTerminatingType returned True for such AbstractTyCons - IfaceToCore set the unary flag to False in the DFunId So we could end up speculating bottom dictionaries because inside a module loop we see an UnaryClassTyCon as an AbstractTyCon Use isTerminatingTyCon, which returns False for an abstract TyCon. The Bool in DFunId is now a cache for isTerminatingTyCon, set in mkDFunIdDetails. Fixes #27704 (cherry picked from commit cd5c6bcc0a59c7b4dc4627fdc7471dc7938d07c2) - - - - - 16e71969 by Zubin Duggal at 2026-09-03T17:39:19+05:30 Specialise: don't replace dead args with absent fillers specHeader decides an argument is dead by calling isDeadBinder on a binder of the /optimised RHS/, then applies the filler to the /stable unfolding/ template instead. The two may differ, so the argument can be dead in the RHS and not in the template. The specialised function's unfolding then has an absent filler, and any call site that inlines it evaluates the error thunk. Dropping dead args in the specialiser is rarely worth it, to quote Simon, "The later worker/wrapper pass will pick up the dead arg later if it is really dead. Keeps the specialiser simpler." So instead of trying to check if the arg really is dead in the stable unfolding, just drop the logic for dropping dead args in the specialiser altogeher. Fixes #27703 (cherry picked from commit abfc224a27cf499390efc5fe1348301fefebb910) - - - - - b2b95f0e by Zubin Duggal at 2026-09-03T17:39:19+05:30 CorePrep: don't speculate a call across an hs-boot edge We take care not to evaluate things that might be bottom, like a looping dictionary group, but our analysis is defeated by boot files. We only track recursion within a module, so two dictionaries that depend on each other across a module loop each look non-recursive, and we might speculate them. Any recursion we cannot see must cross an hs-boot edge, so refuse to speculate calls that cross one. Fixes #27717 (cherry picked from commit 1557fd1cfb802d2608cb5b138eab664564f57fb7) - - - - - 7f2d6ee4 by Cheng Shao at 2026-09-03T17:39:19+05:30 autoconf/ghc-toolchain: bump llvm upper bound to support llvm 23 This commit bumps llvm upper bound to support llvm 23. (cherry picked from commit 56291fc550ec00784e46ec0c89ee65081090ae9f) - - - - - 2c3add31 by Cheng Shao at 2026-09-03T17:39:19+05:30 rts: fix compilation issues with clang 23 clang 23 has broadened `-Wall`/`-Wextra` ranges, exposing some minor issues in the rts when building with validate flavours: - Unused locals - `#pragma GCC diagnostic pop` mismatch This commit fixes those. (cherry picked from commit 20eb3f415f9e04a003322d1a49d95e0aaf1029f2) - - - - - 289 changed files: - + changelog.d/27532 - + changelog.d/27626 - + changelog.d/27627 - + changelog.d/27703 - + changelog.d/27704 - + changelog.d/27717 - + changelog.d/T26423 - + changelog.d/T26716 - changelog.d/T27202 - + changelog.d/T27308 - + changelog.d/T27440 - + changelog.d/T27455 - + changelog.d/T27583 - + changelog.d/T27586 - + changelog.d/T27639 - + changelog.d/T27705 - + changelog.d/arm_ncg_fixes_T27430 - + changelog.d/link-deterministic-order - + changelog.d/llvm-22 - + changelog.d/llvm-23 - + changelog.d/unit-index - compiler/GHC.hs - compiler/GHC/Cmm/Expr.hs - compiler/GHC/Cmm/Lint.hs - compiler/GHC/Cmm/MachOp.hs - compiler/GHC/Cmm/Parser.y - compiler/GHC/CmmToAsm/AArch64/CodeGen.hs - compiler/GHC/CmmToAsm/AArch64/Instr.hs - compiler/GHC/CmmToAsm/AArch64/Ppr.hs - compiler/GHC/Core.hs - compiler/GHC/Core/Opt/Specialise.hs - compiler/GHC/Core/Opt/WorkWrap/Utils.hs - compiler/GHC/Core/TyCon.hs - compiler/GHC/Core/Type.hs - compiler/GHC/Core/Utils.hs - compiler/GHC/CoreToStg/Prep.hs - compiler/GHC/Driver/Backpack.hs - compiler/GHC/Driver/Env.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Pipeline.hs - compiler/GHC/Driver/Session/Units.hs - compiler/GHC/Iface/Load.hs - compiler/GHC/Iface/Recomp.hs - compiler/GHC/IfaceToCore.hs - compiler/GHC/Tc/Gen/Pat.hs - compiler/GHC/Tc/TyCl/PatSyn.hs - compiler/GHC/Tc/Utils/Unify.hs - compiler/GHC/Types/Demand.hs - compiler/GHC/Types/Id/Info.hs - compiler/GHC/Types/Id/Make.hs - compiler/GHC/Types/Literal.hs - compiler/GHC/Types/Unique.hs - compiler/GHC/Types/Unique/DFM.hs - compiler/GHC/Unit.hs - compiler/GHC/Unit/Env.hs - + compiler/GHC/Unit/External/Database.hs - + compiler/GHC/Unit/External/Index.hs - + compiler/GHC/Unit/External/ModuleOrigin.hs - + compiler/GHC/Unit/External/Providers.hs - + compiler/GHC/Unit/External/Query.hs - + compiler/GHC/Unit/External/Substitution.hs - + compiler/GHC/Unit/External/Validate.hs - + compiler/GHC/Unit/External/Visibility.hs - + compiler/GHC/Unit/External/Wired.hs - compiler/GHC/Unit/Home/Graph.hs - compiler/GHC/Unit/Info.hs - compiler/GHC/Unit/State.hs - compiler/GHC/Unit/State.hs-boot - compiler/GHC/Unit/Types.hs - compiler/ghc.cabal.in - configure.ac - docs/index.html.in - docs/users_guide/eventlog-formats.rst - docs/users_guide/ghc_config.py.in - ghc/GHCi/UI.hs - hadrian/src/Rules/Generate.hs - libraries/Cabal - libraries/base/changelog.md - libraries/ghc-heap/GHC/Exts/Heap/FFIClosures_ProfilingDisabled.hsc - libraries/ghc-heap/GHC/Exts/Heap/FFIClosures_ProfilingEnabled.hsc - libraries/ghc-internal/src/GHC/Internal/Conc/Sync.hs - libraries/ghc-internal/src/GHC/Internal/Exception/Type.hs - rts/CloneStack.c - rts/IOManager.c - rts/IOManager.h - rts/Interpreter.c - rts/Messages.c - rts/PrimOps.cmm - rts/ProfHeap.c - rts/Profiling.c - rts/RaiseAsync.c - rts/RaiseAsync.h - rts/STM.c - rts/Schedule.c - rts/StgMiscClosures.cmm - rts/Threads.c - rts/Threads.h - rts/Trace.c - rts/Trace.h - rts/TraverseHeap.c - rts/eventlog/EventLog.c - rts/eventlog/EventLog.h - rts/include/Cmm.h - rts/include/rts/Constants.h - rts/include/rts/EventLogFormat.h - rts/include/rts/storage/Closures.h - rts/include/rts/storage/TSO.h - rts/include/stg/MiscClosures.h - rts/posix/Poll.c - rts/posix/Select.c - rts/posix/Timeout.c - rts/prim/atomic.c - rts/sm/Compact.c - rts/sm/NonMovingMark.c - rts/sm/Sanity.c - rts/sm/Scav.c - rts/win32/AsyncMIO.c - testsuite/tests/cabal/cabal06/Makefile - testsuite/tests/cabal/pkg_bytecode.stderr - testsuite/tests/cabal/pkg_bytecode_foreign.stderr - testsuite/tests/cabal/pkg_bytecode_with_gbc.stderr - testsuite/tests/cabal/pkg_bytecode_with_o.stderr - + testsuite/tests/codeGen/should_run/T27430.hs - + testsuite/tests/codeGen/should_run/T27430.stdout - + testsuite/tests/codeGen/should_run/T27430_c.c - + testsuite/tests/codeGen/should_run/T27533.hs - + testsuite/tests/codeGen/should_run/T27533.stdout - + testsuite/tests/codeGen/should_run/T27533_cmm.cmm - + testsuite/tests/codeGen/should_run/T27537.hs - + testsuite/tests/codeGen/should_run/T27537.stdout - + testsuite/tests/codeGen/should_run/T27538.hs - + testsuite/tests/codeGen/should_run/T27538.stdout - testsuite/tests/codeGen/should_run/all.T - + testsuite/tests/core-to-stg/T27627/Callee.hs - + testsuite/tests/core-to-stg/T27627/Caller.hs - + testsuite/tests/core-to-stg/T27627/Main.hs - + testsuite/tests/core-to-stg/T27627/T27627.stdout - + testsuite/tests/core-to-stg/T27627/all.T - + testsuite/tests/core-to-stg/T27627a/Callee.hs - + testsuite/tests/core-to-stg/T27627a/Caller.hs - + testsuite/tests/core-to-stg/T27627a/Main.hs - + testsuite/tests/core-to-stg/T27627a/T27627a.stdout - + testsuite/tests/core-to-stg/T27627a/all.T - + testsuite/tests/core-to-stg/T27627b/Callee.hs - + testsuite/tests/core-to-stg/T27627b/Caller.hs - + testsuite/tests/core-to-stg/T27627b/Main.hs - + testsuite/tests/core-to-stg/T27627b/T27627b.stdout - + testsuite/tests/core-to-stg/T27627b/all.T - + testsuite/tests/core-to-stg/T27627c/Callee.hs - + testsuite/tests/core-to-stg/T27627c/Caller.hs - + testsuite/tests/core-to-stg/T27627c/Main.hs - + testsuite/tests/core-to-stg/T27627c/T27627c.stdout - + testsuite/tests/core-to-stg/T27627c/all.T - + testsuite/tests/core-to-stg/T27627e.hs - + testsuite/tests/core-to-stg/T27627e.stdout - + testsuite/tests/core-to-stg/T27627f/Callee.hs - + testsuite/tests/core-to-stg/T27627f/Caller.hs - + testsuite/tests/core-to-stg/T27627f/Inst.hs - + testsuite/tests/core-to-stg/T27627f/Main.hs - + testsuite/tests/core-to-stg/T27627f/T27627f.stdout - + testsuite/tests/core-to-stg/T27627f/all.T - + testsuite/tests/core-to-stg/T27704/Callee.hs - + testsuite/tests/core-to-stg/T27704/Callee.hs-boot - + testsuite/tests/core-to-stg/T27704/Main.hs - + testsuite/tests/core-to-stg/T27704/Mid.hs - + testsuite/tests/core-to-stg/T27704/T27704.stdout - + testsuite/tests/core-to-stg/T27704/all.T - + testsuite/tests/core-to-stg/T27704a/Callee.hs - + testsuite/tests/core-to-stg/T27704a/Callee.hs-boot - + testsuite/tests/core-to-stg/T27704a/Main.hs - + testsuite/tests/core-to-stg/T27704a/Mid.hs - + testsuite/tests/core-to-stg/T27704a/T27704a.stdout - + testsuite/tests/core-to-stg/T27704a/all.T - + testsuite/tests/core-to-stg/T27717/Callee.hs - + testsuite/tests/core-to-stg/T27717/Callee.hs-boot - + testsuite/tests/core-to-stg/T27717/Main.hs - + testsuite/tests/core-to-stg/T27717/Mid.hs - + testsuite/tests/core-to-stg/T27717/T27717.stdout - + testsuite/tests/core-to-stg/T27717/Ty.hs - + testsuite/tests/core-to-stg/T27717/all.T - testsuite/tests/core-to-stg/all.T - testsuite/tests/count-deps/CountDepsAst.stdout - testsuite/tests/count-deps/CountDepsParser.stdout - + testsuite/tests/dmdanal/should_run/M2.hs - + testsuite/tests/dmdanal/should_run/T27626.hs - + testsuite/tests/dmdanal/should_run/T27626.stdout - testsuite/tests/dmdanal/should_run/all.T - + testsuite/tests/driver/T26423/Hello.hs - + testsuite/tests/driver/T26423/Makefile - + testsuite/tests/driver/T26423/T26423.hs - + testsuite/tests/driver/T26423/T26423.stderr - + testsuite/tests/driver/T26423/T26423.stdout - + testsuite/tests/driver/T26423/all.T - + testsuite/tests/driver/T26423/test/Test.hs - + testsuite/tests/driver/T26423/test/test.pkg - testsuite/tests/driver/T4437.hs - testsuite/tests/driver/T4437.stdout - + testsuite/tests/driver/TUnitInfo/Foo.hs - + testsuite/tests/driver/TUnitInfo/Makefile - + testsuite/tests/driver/TUnitInfo/all.T - + testsuite/tests/driver/TUnitInfo/genMhu.sh - + testsuite/tests/driver/TUnitInfo/generic-unit-info-space-mhu.stdout - + testsuite/tests/driver/TUnitInfo/generic-unit-info-space-single.stdout - + testsuite/tests/driver/TUnitInfo/generic-unit-info-space.hs - + testsuite/tests/driver/TUnitInfo/generic-unit-info-space.stdout - testsuite/tests/ghc-e/should_fail/T18441fail7.stderr - testsuite/tests/ghc-e/should_run/ghc-e005.stderr - testsuite/tests/ghci/T16793/T16793.stdout - testsuite/tests/ghci/T18060/T18060.stdout - + testsuite/tests/ghci/T27532/Makefile - + testsuite/tests/ghci/T27532/T27532.stdout - + testsuite/tests/ghci/T27532/T27532j4.stdout - + testsuite/tests/ghci/T27532/a.script - + testsuite/tests/ghci/T27532/all.T - + testsuite/tests/ghci/T27532/b.script - + testsuite/tests/ghci/T27532/genT27532Modules - + testsuite/tests/ghci/prog-mhu007/Makefile - + testsuite/tests/ghci/prog-mhu007/a/A.hs - + testsuite/tests/ghci/prog-mhu007/all.T - + testsuite/tests/ghci/prog-mhu007/b/B.hs - + testsuite/tests/ghci/prog-mhu007/prog-mhu007.script - + testsuite/tests/ghci/prog-mhu007/prog-mhu007.stdout - + testsuite/tests/ghci/prog-mhu007/testpkg-bar/Bar.hs - + testsuite/tests/ghci/prog-mhu007/testpkg-bar/testpkg-bar.pkg - + testsuite/tests/ghci/prog-mhu007/testpkg-foo/Foo.hs - + testsuite/tests/ghci/prog-mhu007/testpkg-foo/testpkg-foo.pkg - + testsuite/tests/ghci/prog-mhu007/unitA - + testsuite/tests/ghci/prog-mhu007/unitB - testsuite/tests/ghci/scripts/ListTuplePunsPpr.stdout - testsuite/tests/ghci/scripts/T4175.stdout - testsuite/tests/ghci/scripts/T8469.stdout - testsuite/tests/ghci/scripts/T8535.stdout - testsuite/tests/ghci/scripts/T9881.stdout - testsuite/tests/ghci/scripts/ghci020.stdout - testsuite/tests/ghci/scripts/ghci064.stdout - testsuite/tests/ghci/should_run/T10145.stdout - testsuite/tests/ghci/should_run/T18594.stdout - testsuite/tests/partial-sigs/should_compile/ExtraConstraints3.stderr - + testsuite/tests/patsyn/should_compile/T27440a.hs - + testsuite/tests/patsyn/should_compile/T27440b.hs - + testsuite/tests/patsyn/should_compile/T27440c.hs - testsuite/tests/patsyn/should_compile/all.T - + testsuite/tests/patsyn/should_fail/T27440d.hs - + testsuite/tests/patsyn/should_fail/T27440d.stderr - testsuite/tests/patsyn/should_fail/all.T - + testsuite/tests/rep-poly/T27639.hs - testsuite/tests/rep-poly/all.T - testsuite/tests/roles/should_compile/Roles14.stderr - testsuite/tests/roles/should_compile/Roles3.stderr - testsuite/tests/roles/should_compile/Roles4.stderr - testsuite/tests/roles/should_compile/T8958.stderr - + testsuite/tests/simd/should_run/T27565.hs - + testsuite/tests/simd/should_run/T27565.stdout - testsuite/tests/simd/should_run/all.T - testsuite/tests/simplCore/should_compile/T17966.stderr - testsuite/tests/simplCore/should_compile/T7785.stderr - testsuite/tests/simplCore/should_compile/spec004.hs - testsuite/tests/simplCore/should_compile/spec004.stderr - + testsuite/tests/simplCore/should_run/T27703/Lib.hs - + testsuite/tests/simplCore/should_run/T27703/Main.hs - + testsuite/tests/simplCore/should_run/T27703/T27703.stdout - + testsuite/tests/simplCore/should_run/T27703/all.T - + testsuite/tests/simplCore/should_run/T27705.hs - + testsuite/tests/simplCore/should_run/T27705.stdout - + testsuite/tests/simplCore/should_run/T27705_Inst.hs - testsuite/tests/simplCore/should_run/all.T - testsuite/tests/typecheck/should_compile/T18406b.stderr - testsuite/tests/typecheck/should_compile/T18529.stderr - testsuite/tests/typecheck/should_fail/T5300.stderr - + testsuite/tests/vdq-rta/should_compile/T27583a.hs - + testsuite/tests/vdq-rta/should_compile/T27583b.hs - + testsuite/tests/vdq-rta/should_compile/T27583c.hs - + testsuite/tests/vdq-rta/should_compile/T27583d.hs - + testsuite/tests/vdq-rta/should_compile/T27583e.hs - + testsuite/tests/vdq-rta/should_compile/T27583g.hs - testsuite/tests/vdq-rta/should_compile/all.T - + testsuite/tests/vdq-rta/should_fail/T27440e.hs - + testsuite/tests/vdq-rta/should_fail/T27440e.stderr - + testsuite/tests/vdq-rta/should_fail/T27583f.hs - + testsuite/tests/vdq-rta/should_fail/T27583f.stderr - + testsuite/tests/vdq-rta/should_fail/T27586a.hs - + testsuite/tests/vdq-rta/should_fail/T27586a.stderr - + testsuite/tests/vdq-rta/should_fail/T27586b.hs - + testsuite/tests/vdq-rta/should_fail/T27586b.stderr - + testsuite/tests/vdq-rta/should_fail/T27586c.hs - + testsuite/tests/vdq-rta/should_fail/T27586c.stderr - testsuite/tests/vdq-rta/should_fail/all.T - utils/haddock/haddock-api/src/Haddock.hs - utils/haddock/haddock-test/src/Test/Haddock/Config.hs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/2a27443fade797e9b5db4163f43db53... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/2a27443fade797e9b5db4163f43db53... You're receiving this email because of your account on gitlab.haskell.org. Manage all notifications: https://gitlab.haskell.org/-/profile/notifications | Help: https://gitlab.haskell.org/help