Zubin pushed to branch wip/9.12.3-backports at Glasgow Haskell Compiler / GHC Commits: 79107607 by Berk Özkütük at 2025-08-29T16:10:45+05:30 Consider `PromotedDataCon` in `tyConStupidTheta` Haddock checks data declarations for the stupid theta so as not to pretty-print them as empty contexts. Type data declarations end up as `PromotedDataCon`s by the time Haddock performs this check, causing a panic. This commit extends `tyConStupidTheta` so that it returns an empty list for `PromotedDataCon`s. This decision was guided by the fact that type data declarations never have data type contexts (see (R1) in Note [Type data declarations]). Fixes #25739. (cherry picked from commit 8d33d048dbe159a045a4c304fa92318365a3dfe2) - - - - - a66220ec by Cheng Shao at 2025-08-29T16:10:45+05:30 compiler: fix GHC.SysTools.Ar archive member size writing logic This patch fixes a long-standing bug in `GHC.SysTools.Ar` that emits the wrong archive member size in each archive header. It should encode the exact length of the member payload, excluding any padding byte, otherwise malformed archive that extracts a broken object with an extra trailing byte could be created. Apart from the in-tree `T26120` test, I've also created an out-of-tree testsuite at https://github.com/TerrorJack/ghc-ar-quickcheck that contains QuickCheck roundtrip tests for `GHC.SysTools.Ar`. With this fix, simple roundtrip tests and `writeGNUAr`/GNU `ar` roundtrip test passes. There might be more bugs lurking in here, but this patch is still a critical bugfix already. Fixes #26120 #22586. Co-authored-by: Codex <codex@openai.com> (cherry picked from commit 894a04f3a82dd39ecef71619e2032c4dfead556e) - - - - - f207bcf4 by Teo Camarasu at 2025-08-29T16:10:45+05:30 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) - - - - - e8747fc1 by Andreas Klebinger at 2025-08-29T16:10:45+05:30 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) - - - - - b6da9cb7 by Zubin Duggal at 2025-08-29T16:10:45+05:30 fetch_gitlab: Ensure we copy users_guide.pdf and Haddock.pdf to the release docs directory Fixes #24093 (cherry picked from commit 9fa590a6e27545995cdcf419ed7a6504e6668b18) - - - - - 9f99c921 by Sebastian Graf at 2025-08-29T16:10:45+05:30 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) - - - - - 545c5124 by Ben Gamari at 2025-08-29T16:10:45+05:30 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) - - - - - bb5b81ec by Simon Peyton Jones at 2025-08-29T16:10:45+05:30 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) - - - - - 24fa8925 by Andreas Klebinger at 2025-08-29T16:10:45+05:30 Make unexpected LLVM versions a warning rather than an error. Typically a newer LLVM version *will* work so erroring out if a user uses a newer LLVM version is too aggressive. Fixes #25915 (cherry picked from commit 50842f83f467ff54dd22470559a7af79d2025c03) - - - - - 2f28d46b by Teo Camarasu at 2025-08-29T16:10:45+05:30 rts: spin if we see a WHITEHOLE in messageBlackHole When a BLACKHOLE gets cancelled in raiseAsync, we indirect to a THUNK. GC can then shortcut this, replacing our BLACKHOLE with a fresh THUNK. This THUNK is not guaranteed to have a valid indirectee field. If at the same time, a message intended for the previous BLACKHOLE is processed and concurrently we BLACKHOLE the THUNK, thus temporarily turning it into a WHITEHOLE, we can get a segfault, since we look at the undefined indirectee field of the THUNK The fix is simple: spin if we see a WHITEHOLE, and it will soon be replaced with a valid BLACKHOLE. Resolves #26205 (cherry picked from commit 4021181ee0860aca2054883a531f3312361cc701) - - - - - 9fad9a46 by Teo Camarasu at 2025-08-29T16:10:45+05:30 rts: ensure MessageBlackHole.link is always a valid closure We turn a MessageBlackHole into an StgInd in wakeBlockingQueue(). Therefore it's important that the link field, which becomes the indirection field, always points to a valid closure. It's unclear whether it's currently possible for the previous behaviour to lead to a crash, but it's good to be consistent about this invariant nonetheless. Co-authored-by: Andreas Klebinger <klebinger.andreas@gmx.at> (cherry picked from commit a8b2fbae6bcf20bc2f3fe58803096d2a9c5fc43d) - - - - - ba3e81d4 by Reed Mullanix at 2025-08-29T16:10:45+05:30 ghc-internal: Fix naturalAndNot for NB/NS case When the first argument to `naturalAndNot` is larger than a `Word` and the second is `Word`-sized, `naturalAndNot` will truncate the result: ```

...

...

naturalAndNot ((2 ^ 65) .|. (2 ^ 3)) (2 ^ 3) 0

In contrast, `naturalAndNot` does not truncate when both arguments are larger than a `Word`, so this appears to be a bug.
Luckily, the fix is pretty easy: we just need to call `bigNatAndNotWord#` instead of truncating.

Fixes #26230

(cherry picked from commit a766286fe759251eceb304c54ba52841c2a51f86)

- - - - -
75d546fe by Ben Gamari at 2025-08-29T16:10:45+05:30
llvmGen: Fix built-in variable predicate

Previously the predicate to identify LLVM builtin global variables was
checking for `$llvm` rather than `@llvm` as it should.

(cherry picked from commit 6e67fa083a50684e1cfae546e07cab4d4250e871)

- - - - -


35 changed files:

- .gitlab/rel_eng/fetch-gitlab-artifacts/fetch_gitlab.py
- compiler/GHC/CmmToLlvm/Base.hs
- compiler/GHC/Core/LateCC/OverloadedCalls.hs
- compiler/GHC/Core/Opt/CprAnal.hs
- compiler/GHC/Core/Opt/WorkWrap/Utils.hs
- compiler/GHC/Core/TyCon.hs
- compiler/GHC/Driver/Errors/Ppr.hs
- compiler/GHC/SysTools/Ar.hs
- compiler/GHC/Tc/Solver/Equality.hs
- configure.ac
- docs/users_guide/profiling.rst
- libraries/base/changelog.md
- libraries/ghc-bignum/changelog.md
- libraries/ghc-bignum/src/GHC/Num/Natural.hs
- rts/Messages.c
- rts/StgMiscClosures.cmm
- rts/Updates.h
- rts/sm/NonMoving.c
- rts/sm/NonMoving.h
- rts/sm/NonMovingAllocate.c
- rts/sm/Sanity.c
- + testsuite/tests/cpranal/sigs/T25944.hs
- + testsuite/tests/cpranal/sigs/T25944.stderr
- testsuite/tests/cpranal/sigs/all.T
- testsuite/tests/ghc-api/all.T
- + testsuite/tests/numeric/should_run/T26230.hs
- + testsuite/tests/numeric/should_run/T26230.stdout
- testsuite/tests/numeric/should_run/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/all.T
- + utils/haddock/html-test/ref/Bug25739.html
- + utils/haddock/html-test/src/Bug25739.hs


The diff was not included because it is too large.


View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e020089959a46aa93927906e7887ef992fd91163...75d546fe58d4532b4f39814c453928e206a1018a

-- 
View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e020089959a46aa93927906e7887ef992fd91163...75d546fe58d4532b4f39814c453928e206a1018a
You're receiving this email because of your account on gitlab.haskell.org.