Andreas Klebinger pushed to branch wip/andreask/9.10.4-batch1 at Glasgow Haskell Compiler / GHC Commits: 2373884c by Brandon Chinn at 2026-10-23T17:53:01+02:00 Fix for alex-3.5.2.0 (#25623) This INLINE pragma for alexScanUser was added in 9.12, but then I ported the change to alex in 3.5.2.0 (https://github.com/haskell/alex/pull/262). I didn't realize that GHC errors on duplicate INLINE pragmas, so this ended up being a breaking change. This change should be backported into 9.12 (cherry picked from commit a1d923786baed5b001c523fd2a76f133be510b04) - - - - - 1a86cc78 by Teo Camarasu at 2026-10-23T18:01:25+02:00 rts/nonmovingGC: remove n_free We remove the nonmovingHeap.n_free variable. We wanted this to track the length of nonmovingHeap.free. But this isn't possible to do atomically. When this isn't accurate we can get a segfault by going past the end of the list. Instead, we just count the length of the list when we grab it in nonmovingPruneFreeSegment. Resolves #26186 (cherry picked from commit 45efaf71d97355f76fe0db5af2fc5b4b67fddf47) - - - - - 1c417885 by Ben Gamari at 2026-10-23T18:04:59+02:00 Bump win32-tarballs to v0.9 (cherry picked from commit 7308276916232706c8c196f929ef05fdffca4ddd) - - - - - 5d72c333 by Andreas Klebinger at 2026-10-23T18:05:47+02:00 Disable -fprof-late-overloaded-calls for join points. Currently GHC considers cost centres as destructive to join contexts. Or in other words this is not considered valid: join f x = ... in ... -> scc<tick> jmp This makes the functionality of `-fprof-late-overloaded-calls` not feasible for join points in general. We used to try to work around this by putting the ticks on the rhs of the join point rather than around the jump. However beyond the loss of accuracy this was broken for recursive join points as we ended up with something like: rec-join f x = scc<tick> ... jmp f x Which similarly is not valid as the tick once again destroys the tail call. One might think we could limit ourselves to non-recursive tail calls and do something clever like: join f x = scc<tick> ... in ... jmp f x And sometimes this works! But sometimes the full rhs would look something like: join g x = .... join f x = scc<tick> ... -> jmp g x Which, would again no longer be valid. I believe in the long run we can make cost centre ticks non-destructive to join points. Or we could keep track of where we are/are not allowed to insert a cost centre. But in the short term I will simply disable the annotation of join calls under this flag. (cherry picked from commit 7da86e165612721c4e09f772a3fdaffc733e9293) - - - - - 361eb284 by Sebastian Graf at 2026-10-23T18:08:36+02:00 CprAnal: Detect recursive newtypes (#25944) While `cprTransformDataConWork` handles recursive data con workers, it did not detect the case when a newtype is responsible for the recursion. This is now detected in the `Cast` case of `cprAnal`. The same reproducer made it clear that `isRecDataCon` lacked congruent handling for `AppTy` and `CastTy`, now fixed. Furthermore, the new repro case T25944 triggered this bug via an infinite loop in `cprFix`, caused by the infelicity in `isRecDataCon`. While it should be much less likely to trigger such an infinite loop now that `isRecDataCon` has been fixed, I made sure to abort the loop after 10 iterations and emitting a warning instead. Fixes #25944. (cherry picked from commit 4bc78496406f7469640faaa46e2f311c05760124) - - - - - 15067627 by Ben Gamari at 2026-10-23T18:09:00+02:00 configure: Allow override of CrossCompiling As noted in #26236, the current inference logic is a bit simplistic. In particular, there are many cases (e.g. building for a new libc) where the target and host triples may differ yet we are still able to run the produced artifacts as native code. Closes #26236. (cherry picked from commit 81577fe7c1913c53608bf03e48f84507be904620) - - - - - ae506c05 by Ben Gamari at 2026-10-23T18:09:25+02:00 rts/linker/LoadArchive: Use bool Improve type precision by using `bool` instead of `int` and `StgBool`. (cherry picked from commit 580a33536e6180ce1d623d0922f7de5c975b6b3e) - - - - - a408ab4f by Ben Gamari at 2026-10-23T18:09:25+02:00 rts/linker/LoadArchive: Don't rely on file extensions for identification Previously archive members would be identified via their file extension, as described in #13103. We now instead use a more principled approach, relying on the magic number in the member's header. As well, we refactor treatment of archive format detection to improve code clarity and error handling. Closes #13103. (cherry picked from commit 76d1041dfa4b96108cfdd22b07f2b3feb424dcbe) - - - - - 96d8ff81 by Julian Ospald at 2026-10-23T18:10:37+02:00 rts: Fix object file format detection in loadArchive Commit 76d1041dfa4b96108cfdd22b07f2b3feb424dcbe seems to have introduced this bug, ultimately leading to failure of test T11788. I can only theorize that this test isn't run in upstream's CI, because they don't build a static GHC. The culprit is that we go through the thin archive, trying to follow the members on the filesystem, but don't re-identify the new object format of the member. This pins `object_fmt` to `NotObject` from the thin archive. Thanks to @angerman for spotting this. (cherry picked from commit fc958fc9eb6f6f4db473cdda23c381da8f32163d) - - - - - c57ce901 by Andreas Klebinger at 2026-10-23T18:13:21+02:00 rts: Support COFF BigObj files in archives. (cherry picked from commit 01136779b1d4c1576c925ef673f55c81c45d8551) - - - - - a2cc97f3 by Sylvain Henry at 2026-10-23T18:21:32+02:00 Bump stack resolver to use GHC 9.6.7 Cf #26139 (cherry picked from commit e358e47756b455e167165950fb305b7413366ec4) - - - - - 03541292 by Simon Peyton Jones at 2026-10-23T18:26:08+02:00 Take more care in zonkEqTypes on AppTy/AppTy This patch fixes #26256. See Note [zonkEqTypes and the PKTI] in GHC.Tc.Solver.Equality (cherry picked from commit 18036d5205ac648bb245217519fed2fd931a9982) - - - - - 699c9780 by Cheng Shao at 2026-10-27T12:53:16+01:00 libffi: update to 3.5.2 Bumps libffi submodule. (cherry picked from commit 45dbfa23f508f221b6aeb667783a928511a7654e) - - - - - 35c38e9a by sheaf at 2026-10-27T14:07:58+01:00 Use tcMkScaledFunTys in matchExpectedFunTys We should use tcMkScaledFunTys rather than mkScaledFunTys in GHC.Tc.Utils.Unify.matchExpectedFunTys, as the latter crashes when the kind of the result type is a bare metavariable. We know the result is always Type-like, so we don't need scaledFunTys to try to rediscover that from the kind. Fixes #26277 (cherry picked from commit 624afa4a65caa8ec23f85e70574dfb606f90c173) - - - - - 2b1b7796 by Andreas Klebinger at 2026-10-27T14:29:31+01:00 Bump hadrian directory bound to 1.3.9 for windows. While it's annoying because older releases don't ship it, it seems borderling impossible to build the branch without it on windows. So we use the tighther bound to give builds on windows a chance to finish. - - - - - 664301e9 by Ben Gamari at 2026-10-27T14:46:35+01:00 StgToByteCode: Don't assume that data con workers are nullary Previously StgToByteCode assumed that all data-con workers were of a nullary representation. This is not a valid assumption, as seen in #23210, where an unsaturated application of a unary data constructor's worker resulted in invalid bytecode. Sadly, I have not yet been able to reduce a minimal testcase for this. Fixes #23210. (cherry picked from commit d1d9e39ec293cd1d2b539b8246a349b539c6a61a) - - - - - 09b292df by Ben Gamari at 2026-10-27T14:46:51+01:00 testsuite: Mark T23146* as unbroken (cherry picked from commit 3eeecd508ef80812bc8ee84ab83f496f5030d59b) - - - - - e03f58bd by sheaf at 2026-10-27T14:46:51+01:00 Add test for #26216 (cherry picked from commit 2e73f3426ab6e3cf1938b53831005593f3fd351c) - - - - - 35 changed files: - compiler/GHC/Core/LateCC/OverloadedCalls.hs - compiler/GHC/Core/Opt/CprAnal.hs - compiler/GHC/Core/Opt/WorkWrap/Utils.hs - compiler/GHC/Parser/Lexer.x - compiler/GHC/StgToByteCode.hs - compiler/GHC/Tc/Solver/Equality.hs - compiler/GHC/Tc/Utils/Unify.hs - configure.ac - docs/users_guide/profiling.rst - hadrian/hadrian.cabal - hadrian/stack.yaml - hadrian/stack.yaml.lock - libffi-tarballs - mk/get-win32-tarballs.py - rts/Interpreter.c - rts/linker/LoadArchive.c - rts/sm/NonMoving.c - rts/sm/NonMoving.h - rts/sm/NonMovingAllocate.c - rts/sm/Sanity.c - + testsuite/tests/bytecode/T26216.hs - + testsuite/tests/bytecode/T26216.script - + testsuite/tests/bytecode/T26216.stdout - + testsuite/tests/bytecode/T26216_aux.hs - testsuite/tests/bytecode/all.T - testsuite/tests/codeGen/should_run/T23146/all.T - + testsuite/tests/cpranal/sigs/T25944.hs - + testsuite/tests/cpranal/sigs/T25944.stderr - testsuite/tests/cpranal/sigs/all.T - + testsuite/tests/partial-sigs/should_compile/T26256.hs - + testsuite/tests/partial-sigs/should_compile/T26256.stderr - testsuite/tests/partial-sigs/should_compile/all.T - + testsuite/tests/typecheck/should_compile/T26256a.hs - + testsuite/tests/typecheck/should_compile/T26277.hs - testsuite/tests/typecheck/should_compile/all.T The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/146fc9b7282394c0feaec30b190a8b4... -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/146fc9b7282394c0feaec30b190a8b4... 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