September 2025 - ghc-commits

[Git][ghc/ghc][wip/T26315] 18 commits: cleanup: Move dehydrateCgBreakInfo to Stg2Bc
by Simon Peyton Jones (＠simonpj) 05 Sep '25

05 Sep '25

Simon Peyton Jones pushed to branch wip/T26315 at Glasgow Haskell Compiler / GHC Commits: 79816cc4 by Rodrigo Mesquita at 2025-09-02T12:19:59-04:00 cleanup: Move dehydrateCgBreakInfo to Stg2Bc This no longer has anything to do with Core. - - - - - 53da94ff by Rodrigo Mesquita at 2025-09-02T12:19:59-04:00 rts/Disassembler: Fix spacing of BRK_FUN - - - - - 08c0cf85 by Rodrigo Mesquita at 2025-09-02T12:19:59-04:00 debugger: Fix bciPtr in Step-out We need to use `BCO_NEXT` to move bciPtr to ix=1, because ix=0 points to the instruction itself! I do not understand how this didn't crash before. - - - - - e7e021fa by Rodrigo Mesquita at 2025-09-02T12:19:59-04:00 debugger: Allow BRK_FUNs to head case continuation BCOs When we start executing a BCO, we may want to yield to the scheduler: this may be triggered by a heap/stack check, context switch, or a breakpoint. To yield, we need to put the stack in a state such that when execution is resumed we are back to where we yielded from. Previously, a BKR_FUN could only head a function BCO because we only knew how to construct a valid stack for yielding from one -- simply add `apply_interp_info` + the BCO to resume executing. This is valid because the stack at the start of run_BCO is headed by that BCO's arguments. However, in case continuation BCOs (as per Note [Case continuation BCOs]), we couldn't easily reconstruct a valid stack that could be resumed because we dropped too soon the stack frames regarding the value returned (stg_ret) and received (stg_ctoi) by that continuation. This is especially tricky because of the variable type and size return frames (e.g. pointer ret_p/ctoi_R1p vs a tuple ret_t/ctoi_t2). The trick to being able to yield from a BRK_FUN at the start of a case cont BCO is to stop removing the ret frame headers eagerly and instead keep them until the BCO starts executing. The new layout at the start of a case cont. BCO is described by the new Note [Stack layout when entering run_BCO]. Now, we keep the ret_* and ctoi_* frames when entering run_BCO. A BRK_FUN is then executed if found, and the stack is yielded as-is with the preserved ret and ctoi frames. Then, a case cont BCO's instructions always SLIDE off the headers of the ret and ctoi frames, in StgToByteCode.doCase, turning a stack like | .... | +---------------+ | fv2 | +---------------+ | fv1 | +---------------+ | BCO | +---------------+ | stg_ctoi_ret_ | +---------------+ | retval | +---------------+ | stg_ret_..... | +---------------+ into | .... | +---------------+ | fv2 | +---------------+ | fv1 | +---------------+ | retval | +---------------+ for the remainder of the BCO. Moreover, this more uniform approach of keeping the ret and ctoi frames means we need less ad-hoc logic concerning the variable size of ret_tuple vs ret_p/np frames in the code generator and interpreter: Always keep the return to cont. stack intact at the start of run_BCO, and the statically generated instructions will take care of adjusting it. Unlocks BRK_FUNs at the start of case cont. BCOs which will enable a better user-facing step-out (#26042) which is free of the bugs the current BRK_ALTS implementation suffers from (namely, using BRK_FUN rather than BRK_ALTS in a case cont. means we'll never accidentally end up in a breakpoint "deeper" than the continuation, because we stop at the case cont itself rather than on the first breakpoint we evaluate after it). - - - - - ade3c1e6 by Rodrigo Mesquita at 2025-09-02T12:19:59-04:00 BRK_FUN with InternalBreakLocs for code-generation time breakpoints At the start of a case continuation BCO, place a BRK_FUN. This BRK_FUN uses the new "internal breakpoint location" -- allowing us to come up with a valid source location for this breakpoint that is not associated with a source-level tick. For case continuation BCOs, we use the last tick seen before it as the source location. The reasoning is described in Note [Debugger: Stepout internal break locs]. Note how T26042c, which was broken because it displayed the incorrect behavior of the previous step out when we'd end up at a deeper level than the one from which we initiated step-out, is now fixed. As of this commit, BRK_ALTS is now dead code and is thus dropped. Note [Debugger: Stepout internal break locs] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Step-out tells the interpreter to run until the current function returns to where it was called from, and stop there. This is achieved by enabling the BRK_FUN found on the first RET_BCO frame on the stack (See [Note Debugger: Step-out]). Case continuation BCOs (which select an alternative branch) must therefore be headed by a BRK_FUN. An example: f x = case g x of <--- end up here 1 -> ... 2 -> ... g y = ... <--- step out from here - `g` will return a value to the case continuation BCO in `f` - The case continuation BCO will receive the value returned from g - Match on it and push the alternative continuation for that branch - And then enter that alternative. If we step-out of `g`, the first RET_BCO on the stack is the case continuation of `f` -- execution should stop at its start, before selecting an alternative. (One might ask, "why not enable the breakpoint in the alternative instead?", because the alternative continuation is only pushed to the stack *after* it is selected by the case cont. BCO) However, the case cont. BCO is not associated with any source-level tick, it is merely the glue code which selects alternatives which do have source level ticks. Therefore, we have to come up at code generation time with a breakpoint location ('InternalBreakLoc') to display to the user when it is stopped there. Our solution is to use the last tick seen just before reaching the case continuation. This is robust because a case continuation will thus always have a relevant breakpoint location: - The source location will be the last source-relevant expression executed before the continuation is pushed - So the source location will point to the thing you've just stepped out of - Doing :step-local from there will put you on the selected alternative (which at the source level may also be the e.g. next line in a do-block) Examples, using angle brackets (<<...>>) to denote the breakpoint span: f x = case <<g x>> {- step in here -} of 1 -> ... 2 -> ...> g y = <<...>> <--- step out from here ... f x = <<case g x of <--- end up here, whole case highlighted 1 -> ... 2 -> ...>> doing :step-local ... f x = case g x of 1 -> <<...>> <--- stop in the alternative 2 -> ... A second example based on T26042d2, where the source is a do-block IO action, optimised to a chain of `case expressions`. main = do putStrLn "hello1" <<f>> <--- step-in here putStrLn "hello3" putStrLn "hello4" f = do <<putStrLn "hello2.1">> <--- step-out from here putStrLn "hello2.2" ... main = do putStrLn "hello1" <<f>> <--- end up here again, the previously executed expression putStrLn "hello3" putStrLn "hello4" doing step/step-local ... main = do putStrLn "hello1" f <<putStrLn "hello3">> <--- straight to the next line putStrLn "hello4" Finishes #26042 - - - - - c66910c0 by Rodrigo Mesquita at 2025-09-02T12:19:59-04:00 debugger: Re-use the last BreakpointId whole in step-out Previously, to come up with a location to stop at for `:stepout`, we would store the location of the last BreakpointId surrounding the continuation, as described by Note [Debugger: Stepout internal break locs]. However, re-using just the location from the last source breakpoint isn't sufficient to provide the necessary information in the break location. Specifically, it wouldn't bind any variables at that location. Really, there is no reason not to re-use the last breakpoint wholesale, and re-use all the information we had there. Step-out should behave just as if we had stopped at the call, but s.t. continuing will not re-execute the call. This commit updates the CgBreakInfo to always store a BreakpointId, be it the original one or the one we're emulating (for step-out). It makes variable bindings on :stepout work - - - - - e4abed7b by sheaf at 2025-09-02T12:20:40-04:00 Revert accidental changes to hie.yaml - - - - - 003b715b by meooow25 at 2025-09-02T23:48:51+02:00 Adjust the strictness of Data.List.iterate' * Don't force the next element in advance when generating a (:). * Force the first element to WHNF like every other element. Now every element in the output list is forced to WHNF when the (:) containing it is forced. CLC proposal: https://github.com/haskell/core-libraries-committee/issues/335 - - - - - b2f6aad0 by Simon Hengel at 2025-09-03T04:36:10-04:00 Refactoring: More consistently use logOutput, logInfo, fatalErrorMsg - - - - - 60a16db7 by Rodrigo Mesquita at 2025-09-03T10:55:50+01:00 bytecode: Don't PUSH_L 0; SLIDE 1 1 While looking through bytecode I noticed a quite common unfortunate pattern: ... PUSH_L 0 SLIDE 1 1 We do this often by generically constructing a tail call from a function atom that may be somewhere arbitrary on the stack. However, for the special case that the function can be found directly on top of the stack, as part of the arguments, it's plain redundant to push then slide it. In this commit we add a small optimisation to the generation of tailcalls in bytecode. Simply: lookahead for the function in the stack. If it is the first thing on the stack and it is part of the arguments which would be dropped as we entered the tail call, then don't push then slide it. In a simple example (T26042b), this already produced a drastic improvement in generated code (left is old, right is with this patch): ```diff 3c3 < 2025-07-29 10:14:02.081277 UTC --- > 2025-07-29 10:50:36.560949 UTC 160,161c160 < PUSH_L 0 < SLIDE 1 2 --- > SLIDE 1 1 164,165d162 < PUSH_L 0 < SLIDE 1 1 175,176c172 < PUSH_L 0 < SLIDE 1 2 --- > SLIDE 1 1 179,180d174 < PUSH_L 0 < SLIDE 1 1 206,207d199 < PUSH_L 0 < SLIDE 1 1 210,211d201 < PUSH_L 0 < SLIDE 1 1 214,215d203 < PUSH_L 0 < SLIDE 1 1 218,219d205 < PUSH_L 0 < SLIDE 1 1 222,223d207 < PUSH_L 0 < SLIDE 1 1 ... 600,601c566 < PUSH_L 0 < SLIDE 1 2 --- > SLIDE 1 1 604,605d568 < PUSH_L 0 < SLIDE 1 1 632,633d594 < PUSH_L 0 < SLIDE 1 1 636,637d596 < PUSH_L 0 < SLIDE 1 1 640,641d598 < PUSH_L 0 < SLIDE 1 1 644,645d600 < PUSH_L 0 < SLIDE 1 1 648,649d602 < PUSH_L 0 < SLIDE 1 1 652,653d604 < PUSH_L 0 < SLIDE 1 1 656,657d606 < PUSH_L 0 < SLIDE 1 1 660,661d608 < PUSH_L 0 < SLIDE 1 1 664,665d610 < PUSH_L 0 < SLIDE 1 1 ``` I also compiled lib:Cabal to bytecode and counted the number of bytecode lines with `find dist-newstyle -name "*.dump-BCOs" -exec wc {} +`: with unoptimized core: 1190689 lines (before) - 1172891 lines (now) = 17798 less redundant instructions (-1.5% lines) with optimized core: 1924818 lines (before) - 1864836 lines (now) = 59982 less redundant instructions (-3.1% lines) - - - - - 8b2c72c0 by L0neGamer at 2025-09-04T06:32:03-04:00 Add Control.Monad.thenM and Control.Applicative.thenA - - - - - 39e1b7cb by Teo Camarasu at 2025-09-04T06:32:46-04:00 ghc-internal: invert dependency of GHC.Internal.TH.Syntax on Data.Data This means that Data.Data no longer blocks building TH.Syntax, which allows greater parallelism in our builds. We move the Data.Data.Data instances to Data.Data. Quasi depends on Data.Data for one of its methods, so, we split the Quasi/Q, etc definition out of GHC.Internal.TH.Syntax into its own module. This has the added benefit of splitting up this quite large module. Previously TH.Syntax was a bottleneck when compiling ghc-internal. Now it is less of a bottle-neck and is also slightly quicker to compile (since it no longer contains these instances) at the cost of making Data.Data slightly more expensive to compile. TH.Lift which depends on TH.Syntax can also compile quicker and no longer blocks ghc-internal finishing to compile. Resolves #26217 ------------------------- Metric Decrease: MultiLayerModulesTH_OneShot T13253 T21839c T24471 Metric Increase: T12227 ------------------------- - - - - - bdf82fd2 by Teo Camarasu at 2025-09-04T06:32:46-04:00 compiler: delete unused names in Builtins.Names.TH returnQ and bindQ are no longer used in the compiler. There was also a very old comment that referred to them that I have modernized - - - - - 41a448e5 by Ben Gamari at 2025-09-04T19:21:43-04:00 hadrian: Pass lib & include directories to ghc `Setup configure` - - - - - 46bb9a79 by Ben Gamari at 2025-09-04T19:21:44-04:00 rts/IPE: Fix compilation when zstd is enabled This was broken by the refactoring undertaken in c80dd91c0bf6ac034f0c592f16c548b9408a8481. Closes #26312. - - - - - 138a6e34 by sheaf at 2025-09-04T19:22:46-04:00 Make mkCast assertion a bit clearer This commit changes the assertion message that gets printed when one calls mkCast with a coercion whose kind does not match the type of the inner expression. I always found the assertion message a bit confusing, as it didn't clearly state what exactly was the error. - - - - - 9d626be1 by sheaf at 2025-09-04T19:22:46-04:00 Simplifier/rules: fix mistakes in Notes & comments - - - - - a71f55a3 by Simon Peyton Jones at 2025-09-05T09:40:41+01:00 Solve forall-constraints via an implication, again In this earlier commit: commit 953fd8f1dc080f1c56e3a60b4b7157456949be29 Author: Simon Peyton Jones <simon.peytonjones(a)gmail.com> Date: Mon Jul 21 10:06:43 2025 +0100 Solve forall-constraints immediately, or not at all I used a all-or-nothing strategy for quantified constraints (aka forall-constraints). But alas that fell foul of #26315, and #26376. So this MR goes back to solving a quantified constraint by turning it into an implication; UNLESS we are simplifying constraints from a SPECIALISE pragma, in which case the all-or-nothing strategy is great. See: Note [Solving a Wanted forall-constraint] Other stuff in this MR: * TcSMode becomes a record of flags, rather than an enumeration type; much nicer. * Some fancy footwork to avoid error messages worsening again (The above MR made them better; we want to retain that.) See `GHC.Tc.Errors.Ppr.pprQCOriginExtra`. - - - - - 129 changed files: - compiler/GHC/Builtin/Names/TH.hs - compiler/GHC/ByteCode/Asm.hs - compiler/GHC/ByteCode/Breakpoints.hs - compiler/GHC/ByteCode/Instr.hs - compiler/GHC/Core/Lint.hs - compiler/GHC/Core/Opt/Simplify.hs - compiler/GHC/Core/Opt/SpecConstr.hs - compiler/GHC/Core/Rules.hs - compiler/GHC/Core/Utils.hs - compiler/GHC/CoreToIface.hs - compiler/GHC/Data/IOEnv.hs - compiler/GHC/Driver/CodeOutput.hs - compiler/GHC/Driver/Pipeline/Execute.hs - compiler/GHC/Hs/Expr.hs - compiler/GHC/HsToCore/Binds.hs - compiler/GHC/HsToCore/Quote.hs - compiler/GHC/Iface/Load.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Rename/Splice.hs - compiler/GHC/Runtime/Debugger/Breakpoints.hs - compiler/GHC/Runtime/Eval.hs - compiler/GHC/Stg/Lint.hs - compiler/GHC/StgToByteCode.hs - compiler/GHC/Tc/Deriv/Utils.hs - compiler/GHC/Tc/Errors/Ppr.hs - compiler/GHC/Tc/Gen/Sig.hs - compiler/GHC/Tc/Gen/Splice.hs - compiler/GHC/Tc/Gen/Splice.hs-boot - compiler/GHC/Tc/Solver.hs - compiler/GHC/Tc/Solver/Default.hs - compiler/GHC/Tc/Solver/Dict.hs - compiler/GHC/Tc/Solver/Equality.hs - compiler/GHC/Tc/Solver/InertSet.hs - compiler/GHC/Tc/Solver/Monad.hs - compiler/GHC/Tc/Solver/Solve.hs - compiler/GHC/Tc/Solver/Solve.hs-boot - compiler/GHC/Tc/Types/Constraint.hs - compiler/GHC/Tc/Types/Evidence.hs - compiler/GHC/Tc/Types/Origin.hs - compiler/GHC/Tc/Types/TH.hs - compiler/GHC/Tc/Utils/Monad.hs - compiler/GHC/Tc/Zonk/TcType.hs - compiler/GHC/Tc/Zonk/Type.hs - ghc/GHCi/UI.hs - hadrian/src/Settings/Packages.hs - hie.yaml - libraries/base/changelog.md - libraries/base/src/Control/Applicative.hs - libraries/base/src/Control/Monad.hs - libraries/base/src/Data/Array/Byte.hs - libraries/base/src/Data/Fixed.hs - + libraries/ghc-boot-th/GHC/Boot/TH/Monad.hs - libraries/ghc-boot-th/ghc-boot-th.cabal.in - libraries/ghc-internal/ghc-internal.cabal.in - libraries/ghc-internal/src/GHC/Internal/Base.hs - libraries/ghc-internal/src/GHC/Internal/Control/Monad.hs - libraries/ghc-internal/src/GHC/Internal/Data/Data.hs - libraries/ghc-internal/src/GHC/Internal/List.hs - libraries/ghc-internal/src/GHC/Internal/TH/Lib.hs - libraries/ghc-internal/src/GHC/Internal/TH/Lift.hs - + libraries/ghc-internal/src/GHC/Internal/TH/Monad.hs - libraries/ghc-internal/src/GHC/Internal/TH/Quote.hs - libraries/ghc-internal/src/GHC/Internal/TH/Syntax.hs - libraries/ghci/GHCi/Message.hs - libraries/ghci/GHCi/Run.hs - libraries/ghci/GHCi/TH.hs - libraries/template-haskell/Language/Haskell/TH/Quote.hs - libraries/template-haskell/Language/Haskell/TH/Syntax.hs - rts/Disassembler.c - rts/IPE.c - rts/Interpreter.c - rts/Profiling.c - rts/include/rts/Bytecodes.h - testsuite/tests/backpack/should_fail/bkpfail11.stderr - testsuite/tests/backpack/should_fail/bkpfail43.stderr - testsuite/tests/count-deps/CountDepsAst.stdout - testsuite/tests/count-deps/CountDepsParser.stdout - testsuite/tests/deriving/should_compile/T14682.stderr - testsuite/tests/deriving/should_compile/drv-empty-data.stderr - testsuite/tests/deriving/should_fail/T12768.stderr - testsuite/tests/deriving/should_fail/T1496.stderr - testsuite/tests/deriving/should_fail/T21302.stderr - testsuite/tests/deriving/should_fail/T22696b.stderr - testsuite/tests/deriving/should_fail/T5498.stderr - testsuite/tests/deriving/should_fail/T7148.stderr - testsuite/tests/deriving/should_fail/T7148a.stderr - testsuite/tests/ghci.debugger/scripts/T26042b.script - testsuite/tests/ghci.debugger/scripts/T26042b.stdout - testsuite/tests/ghci.debugger/scripts/T26042c.script - testsuite/tests/ghci.debugger/scripts/T26042c.stdout - + testsuite/tests/ghci.debugger/scripts/T26042d2.hs - + testsuite/tests/ghci.debugger/scripts/T26042d2.script - + testsuite/tests/ghci.debugger/scripts/T26042d2.stdout - testsuite/tests/ghci.debugger/scripts/T26042e.stdout - testsuite/tests/ghci.debugger/scripts/T26042f.script - testsuite/tests/ghci.debugger/scripts/T26042f1.stdout - testsuite/tests/ghci.debugger/scripts/T26042f2.stdout - testsuite/tests/ghci.debugger/scripts/T26042g.stdout - testsuite/tests/ghci.debugger/scripts/all.T - testsuite/tests/impredicative/T17332.stderr - testsuite/tests/interface-stability/base-exports.stdout - testsuite/tests/interface-stability/base-exports.stdout-javascript-unknown-ghcjs - testsuite/tests/interface-stability/base-exports.stdout-mingw32 - testsuite/tests/interface-stability/base-exports.stdout-ws-32 - testsuite/tests/interface-stability/template-haskell-exports.stdout - testsuite/tests/plugins/plugins10.stdout - testsuite/tests/profiling/should_run/callstack001.stdout - testsuite/tests/quantified-constraints/T19690.stderr - testsuite/tests/quantified-constraints/T19921.stderr - testsuite/tests/quantified-constraints/T21006.stderr - testsuite/tests/roles/should_fail/RolesIArray.stderr - testsuite/tests/simplCore/should_compile/DsSpecPragmas.hs - testsuite/tests/simplCore/should_compile/DsSpecPragmas.stderr - testsuite/tests/splice-imports/SI29.stderr - testsuite/tests/th/T11452.stderr - testsuite/tests/th/T15321.stderr - testsuite/tests/th/T7276.stderr - testsuite/tests/th/TH_NestedSplicesFail3.stderr - testsuite/tests/th/TH_NestedSplicesFail4.stderr - testsuite/tests/typecheck/should_compile/T14434.hs - + testsuite/tests/typecheck/should_compile/T26376.hs - testsuite/tests/typecheck/should_compile/all.T - testsuite/tests/typecheck/should_fail/T15801.stderr - testsuite/tests/typecheck/should_fail/T19627.stderr - testsuite/tests/typecheck/should_fail/T20666.stderr - testsuite/tests/typecheck/should_fail/T20666a.stderr - testsuite/tests/typecheck/should_fail/T20666b.stderr - testsuite/tests/typecheck/should_fail/T22912.stderr - testsuite/tests/typecheck/should_fail/T23427.stderr The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6a93a2883a2fba1653de0ea71ea57c… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/6a93a2883a2fba1653de0ea71ea57c… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/angerman/ghci-ghc-9.8-compat] Conditionalize the ghc-internal dependency on the ghc version.
by Moritz Angermann (＠angerman) 05 Sep '25

05 Sep '25

Moritz Angermann pushed to branch wip/angerman/ghci-ghc-9.8-compat at Glasgow Haskell Compiler / GHC Commits: 9cc29224 by Moritz Angermann at 2025-09-05T17:32:52+09:00 Conditionalize the ghc-internal dependency on the ghc version. This change reverts part of !14544, which forces the bootstrap compiler to have ghc-internal. As such it breaks booting with ghc 9.8.4. A better solution would be to make this conditional on the ghc version in the cabal file! - - - - - 3 changed files: - libraries/ghci/GHCi/CreateBCO.hs - libraries/ghci/GHCi/TH.hs - libraries/ghci/ghci.cabal.in Changes: ===================================== libraries/ghci/GHCi/CreateBCO.hs ===================================== @@ -6,6 +6,10 @@ {-# LANGUAGE UnboxedTuples #-} {-# LANGUAGE RecordWildCards #-} {-# LANGUAGE CPP #-} +-- Only needed when we don't have ghc-internal (and must import deprecated names) +#ifndef HAVE_GHC_INTERNAL +{-# OPTIONS_GHC -Wno-warnings-deprecations #-} +#endif -- -- (c) The University of Glasgow 2002-2006 @@ -26,8 +30,13 @@ import Data.Array.Base import Foreign hiding (newArray) import Unsafe.Coerce (unsafeCoerce) import GHC.Arr ( Array(..) ) -import GHC.Exts hiding ( BCO, mkApUpd0#, newBCO# ) +-- When ghc-internal is available prefer the non-deprecated exports. +#ifdef HAVE_GHC_INTERNAL +import GHC.Exts hiding ( BCO, mkApUpd0#, newBCO# ) import GHC.Internal.Base ( BCO, mkApUpd0#, newBCO# ) +#else +import GHC.Exts +#endif import GHC.IO import Control.Exception ( ErrorCall(..) ) ===================================== libraries/ghci/GHCi/TH.hs ===================================== @@ -1,6 +1,11 @@ {-# LANGUAGE ScopedTypeVariables, StandaloneDeriving, DeriveGeneric, TupleSections, RecordWildCards, InstanceSigs, CPP #-} {-# OPTIONS_GHC -fno-warn-name-shadowing #-} +-- Suppress deprecation warnings only when we must import deprecated symbols +-- (i.e. when ghc-internal isn't available yet). +#ifndef HAVE_GHC_INTERNAL +{-# OPTIONS_GHC -Wno-warnings-deprecations #-} +#endif -- | -- Running TH splices @@ -109,7 +114,12 @@ import Data.IORef import Data.Map (Map) import qualified Data.Map as M import Data.Maybe +-- Prefer the non-deprecated internal path when available. +#ifdef HAVE_GHC_INTERNAL import GHC.Internal.Desugar (AnnotationWrapper(..)) +#else +import GHC.Desugar (AnnotationWrapper(..)) +#endif import qualified GHC.Boot.TH.Syntax as TH import qualified GHC.Boot.TH.Monad as TH import Unsafe.Coerce ===================================== libraries/ghci/ghci.cabal.in ===================================== @@ -86,7 +86,6 @@ library rts, array == 0.5.*, base >= 4.8 && < 4.23, - ghc-internal >= 9.1001.0 && <=@ProjectVersionForLib@.0, ghc-prim >= 0.5.0 && < 0.14, binary == 0.8.*, bytestring >= 0.10 && < 0.13, @@ -97,6 +96,19 @@ library ghc-heap >= 9.10.1 && <=@ProjectVersionMunged@, transformers >= 0.5 && < 0.7 + if impl(ghc > 9.10) + -- ghc-internal is only available (and required) when building + -- with a compiler that itself provides the ghc-internal + -- library. Older bootstrap compilers (<= 9.10) don't ship it, + -- so we must not depend on it in that case. + -- + -- When available we depend on the in-tree version (matching + -- @ProjectVersionForLib@) and define HAVE_GHC_INTERNAL so that + -- sources can import the non-deprecated modules from + -- GHC.Internal.* instead of the legacy (deprecated) locations. + Build-Depends: >= 9.1001.0 && <=@ProjectVersionForLib@.0, + CPP-Options: -DHAVE_GHC_INTERNAL + if flag(bootstrap) build-depends: ghc-boot-th-next == @ProjectVersionMunged@ View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/9cc292246ec6aebe489f10543e81a59… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/9cc292246ec6aebe489f10543e81a59… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc] Pushed new branch wip/angerman/ghc-pkg-target
by Moritz Angermann (＠angerman) 05 Sep '25

05 Sep '25

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

1 0

[Git][ghc/ghc] Pushed new branch wip/angerman/ghc-pkg-mermaid
by Moritz Angermann (＠angerman) 05 Sep '25

05 Sep '25

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

1 0

[Git][ghc/ghc] Pushed new branch wip/angerman/compiler-ghc-9.8-compat
by Moritz Angermann (＠angerman) 05 Sep '25

05 Sep '25

Moritz Angermann pushed new branch wip/angerman/compiler-ghc-9.8-compat at Glasgow Haskell Compiler / GHC -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/tree/wip/angerman/compiler-ghc-9.8-com… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc] Pushed new branch wip/angerman/ghci-ghc-9.8-compat
by Moritz Angermann (＠angerman) 05 Sep '25

05 Sep '25

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

1 0

[Git][ghc/ghc][ghc-9.14] 4 commits: template-haskell: move some identifiers from ghc-internal to template-haskell
by Ben Gamari (＠bgamari) 05 Sep '25

05 Sep '25

Ben Gamari pushed to branch ghc-9.14 at Glasgow Haskell Compiler / GHC Commits: 19ad5a57 by Teo Camarasu at 2025-09-04T15:40:55-04:00 template-haskell: move some identifiers from ghc-internal to template-haskell These identifiers are not used internally by the compiler. Therefore we have no reason for them to be in ghc-internal. By moving them to template-haskell, we benefit from it being easier to change them and we avoid having to build them in stage0. Resolves #26048 (cherry picked from commit 5b841d824afba607de31f9dafae3afca9ce528b9) - - - - - dc6a534d by sheaf at 2025-09-04T15:42:47-04:00 Back-compat for TH SpecialiseP data-con of Pragma This commit improves the backwards-compatibility story for the SpecialiseP constructor of the Template Haskell 'Pragma' datatype. Instead of keeping the constructor but deprecating it, this commit makes it into a bundled pattern synonym of the Pragma datatype. We no longer deprecate it; it's useful for handling old-form specialise pragmas. (cherry picked from commit 27206c5e3c8e6f878f509d6a8f648a212f648a75) - - - - - 208763ab by Sylvain Henry at 2025-09-04T15:43:11-04:00 Driver: substitute virtual Prim module in --make mode too When we build ghc-internal with --make (e.g. with cabal-install), we need to be careful to substitute the virtual interface file for GHC.Internal.Prim: - after code generation (we generate code for an empty module, so we get an empty interface) - when we try to reload its .hi file (cherry picked from commit 6c78de2d6506bbbd9952ef884bdb60df8f8cf9f8) - - - - - ba0dd3db by Rodrigo Mesquita at 2025-09-04T15:47:01-04:00 debugger: Uniquely identify breakpoints by internal id Since b85b11994e0130ff2401dd4bbdf52330e0bcf776 (support inlining breakpoints), a breakpoint has been identified at runtime by *two* pairs of <module,index>. - The first, aka a 'BreakpointId', uniquely identifies a breakpoint in the source of a module by using the Tick index. A Tick index can index into ModBreaks.modBreaks_xxx to fetch source-level information about where that tick originated. - When a user specifies e.g. a line breakpoint using :break, we'll reverse engineer what a Tick index for that line - We update the `BreakArray` of that module (got from the LoaderState) at that tick index to `breakOn`. - A BCO we can stop at is headed by a BRK_FUN instruction. This instruction stores in an operand the `tick index` it is associated to. We look it up in the associated `BreakArray` (also an operand) and check wheter it was set to `breakOn`. - The second, aka the `ibi_info_mod` + `ibi_info_ix` of the `InternalBreakpointId`, uniquely index into the `imodBreaks_breakInfo` -- the information we gathered during code generation about the existing breakpoint *ocurrences*. - Note that with optimisation there may be many occurrences of the same source-tick-breakpoint across different modules. The `ibi_info_ix` is unique per occurrence, but the `bi_tick_ix` may be shared. See Note [Breakpoint identifiers] about this. - Note that besides the tick ids, info ids are also stored in `BRK_FUN` so the break handler can refer to the associated `CgBreakInfo`. In light of that, the driving changes come from the desire to have the info_id uniquely identify the breakpoint at runtime, and the source tick id being derived from it: - An InternalBreakpointId should uniquely identify a breakpoint just from the code-generation identifiers of `ibi_info_ix` and `ibi_info_mod`. So we drop `ibi_tick_mod` and `ibi_tick_ix`. - A BRK_FUN instruction need only record the "internal breakpoint id", not the tick-level id. So we drop the tick mod and tick index operands. - A BreakArray should be indexed by InternalBreakpointId rather than BreakpointId That means we need to do some more work when setting a breakpoint. Specifically, we need to figure out the internal ids (occurrences of a breakpoint) from the source-level BreakpointId we want to set the breakpoint at (recall :break refers to breaks at the source level). Besides this change being an improvement to the handling of breakpoints (it's clearer to have a single unique identifier than two competing ones), it unlocks the possibility of generating "internal" breakpoints during Cg (needed for #26042). It should also be easier to introduce multi-threaded-aware `BreakArrays` following this change (needed for #26064). Se also the new Note [ModBreaks vs InternalModBreaks] On i386-linux: ------------------------- Metric Decrease: interpreter_steplocal ------------------------- (cherry picked from commit 083e40f1ea7fa13faac282456c357a8541e8e6bd) - - - - - 44 changed files: - compiler/GHC/ByteCode/Asm.hs - compiler/GHC/ByteCode/Breakpoints.hs - compiler/GHC/ByteCode/Instr.hs - compiler/GHC/ByteCode/Linker.hs - compiler/GHC/ByteCode/Types.hs - compiler/GHC/CoreToIface.hs - compiler/GHC/Driver/Downsweep.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Make.hs - compiler/GHC/Driver/Pipeline.hs - compiler/GHC/HsToCore/Breakpoints.hs - compiler/GHC/Iface/Load.hs - compiler/GHC/Iface/Recomp.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Runtime/Debugger/Breakpoints.hs - compiler/GHC/Runtime/Eval.hs - compiler/GHC/Runtime/Interpreter.hs - compiler/GHC/StgToByteCode.hs - compiler/GHC/ThToHs.hs - ghc/GHCi/UI.hs - ghc/GHCi/UI/Monad.hs - libraries/ghc-boot-th/GHC/Boot/TH/Ppr.hs - libraries/ghc-internal/src/GHC/Internal/TH/Lib.hs - libraries/ghc-internal/src/GHC/Internal/TH/Lift.hs - libraries/ghc-internal/src/GHC/Internal/TH/Syntax.hs - libraries/ghci/GHCi/Debugger.hs - libraries/ghci/GHCi/Message.hs - libraries/ghci/GHCi/Run.hs - libraries/template-haskell/Language/Haskell/TH/Lib.hs - libraries/template-haskell/Language/Haskell/TH/Quote.hs - libraries/template-haskell/Language/Haskell/TH/Syntax.hs - libraries/template-haskell/changelog.md - libraries/template-haskell/tests/all.T - rts/Disassembler.c - rts/Exception.cmm - rts/Interpreter.c - + testsuite/tests/driver/make-prim/GHC/Internal/Prim.hs - + testsuite/tests/driver/make-prim/Makefile - + testsuite/tests/driver/make-prim/Test.hs - + testsuite/tests/driver/make-prim/Test2.hs - + testsuite/tests/driver/make-prim/all.T - testsuite/tests/interface-stability/template-haskell-exports.stdout - testsuite/tests/quasiquotation/T4491/test.T - testsuite/tests/th/Makefile The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f6a086c355eb027cc40a2b9645eedd… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/f6a086c355eb027cc40a2b9645eedd… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc] Deleted branch wip/backports-9.14
by Ben Gamari (＠bgamari) 05 Sep '25

05 Sep '25

Ben Gamari deleted branch wip/backports-9.14 at Glasgow Haskell Compiler / GHC -- You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/sol/remove-ddump-json] 48 commits: Revert "STM: don't create a transaction in the rhs of catchRetry# (#26028)"
by Simon Hengel (＠sol) 05 Sep '25

05 Sep '25

Simon Hengel pushed to branch wip/sol/remove-ddump-json at Glasgow Haskell Compiler / GHC Commits: 5b5d9d47 by Ben Gamari at 2025-08-25T14:29:35-04:00 Revert "STM: don't create a transaction in the rhs of catchRetry# (#26028)" This reverts commit 0a5836891ca29836a24c306d2a364c2e4b5377fd - - - - - 10f06163 by Cheng Shao at 2025-08-25T14:30:16-04:00 wasm: ensure setKeepCAFs() is called in ghci This patch is a critical bugfix for #26106, see comment and linked issue for details. - - - - - bedc1004 by Cheng Shao at 2025-08-26T09:31:18-04:00 compiler: use zero cost coerce in hoopl setElems/mapToList This patch is a follow-up of !14680 and changes setElems/mapToList in GHC/Cmm/Dataflow/Label to use coerce instead of mapping mkHooplLabel over the keys. - - - - - 13250d97 by Ryan Scott at 2025-08-26T09:31:59-04:00 Reject infix promoted data constructors without DataKinds In the rename, make sure to apply the same `DataKinds` checks for both `HsTyVar` (for prefix promoted data constructors) and `HsOpTy` (for infix promoted data constructors) alike. Fixes #26318. - - - - - 37655c46 by Teo Camarasu at 2025-08-26T15:24:51-04:00 tests: disable T22859 under LLVM This test was failing under the LLVM backend since the allocations differ from the NCG. Resolves #26282 - - - - - 2cbba9d6 by Teo Camarasu at 2025-08-26T15:25:33-04:00 base-exports: update version numbers As the version of the compiler has been bumped, a lot of the embedded version numbers will need to be updated if we ever run this test with `--test-accept` so let's just update them now, and keep future diffs clean. - - - - - f9f2ffcf by Alexandre Esteves at 2025-08-27T07:19:14-04:00 Import new name for 'utimbuf' on windows to fix #26337 Fixes an `-Wincompatible-pointer-types` instance that turns into an error on recent toolchains and surfaced as such on nixpkgs when doing linux->ucrt cross. This long-standing warning has been present at least since 9.4: ``` C:\GitLabRunner\builds\0\1709189\tmp\ghc16652_0\ghc_4.c:26:115: error: warning: incompatible pointer types passing 'struct utimbuf *' to parameter of type 'struct _utimbuf *' [-Wincompatible-pointer-types] | 26 | HsInt32 ghczuwrapperZC9ZCbaseZCSystemziPosixziInternalsZCzuutime(char* a1, struct utimbuf* a2) {return _utime(a1, a2);} | ^ HsInt32 ghczuwrapperZC9ZCbaseZCSystemziPosixziInternalsZCzuutime(char* a1, struct utimbuf* a2) {return _utime(a1, a2);} ^~ C:\GitLabRunner\builds\0\1709189\_build\stage0\lib\..\..\mingw\x86_64-w64-mingw32\include\sys\utime.h:109:72: error: note: passing argument to parameter '_Utimbuf' here | 109 | __CRT_INLINE int __cdecl _utime(const char *_Filename,struct _utimbuf *_Utimbuf) { | ^ __CRT_INLINE int __cdecl _utime(const char *_Filename,struct _utimbuf *_Utimbuf) { ``` - - - - - ae89f000 by Hassan Al-Awwadi at 2025-08-27T07:19:56-04:00 Adds the fucnction addDependentDirectory to Q, resolving issue #26148. This function adds a new directory to the list of things a module depends upon. That means that when the contents of the directory change, the recompilation checker will notice this and the module will be recompiled. Documentation has also been added for addDependentFunction and addDependentDirectory in the user guide. - - - - - 00478944 by Simon Peyton Jones at 2025-08-27T16:48:30+01:00 Comments only - - - - - a7884589 by Simon Peyton Jones at 2025-08-28T11:08:23+01:00 Type-family occurs check in unification The occurs check in `GHC.Core.Unify.uVarOrFam` was inadequate in dealing with type families. Better now. See Note [The occurs check in the Core unifier]. As I did this I realised that the whole apartness thing is trickier than I thought: see the new Note [Shortcomings of the apartness test] - - - - - 8adfc222 by sheaf at 2025-08-28T19:47:17-04:00 Fix orientation in HsWrapper composition (<.>) This commit fixes the order in which WpCast HsWrappers are composed, fixing a bug introduced in commit 56b32c5a2d5d7cad89a12f4d74dc940e086069d1. Fixes #26350 - - - - - eb2ab1e2 by Oleg Grenrus at 2025-08-29T11:00:53-04:00 Generalise thNameToGhcName by adding HasHscEnv There were multiple single monad-specific `getHscEnv` across codebase. HasHscEnv is modelled on HasDynFlags. My first idea was to simply add thNameToGhcNameHsc and thNameToGhcNameTc, but those would been exactly the same as thNameToGhcName already. Also add an usage example to thNameToGhcName and mention that it's recommended way of looking up names in GHC plugins - - - - - 2d575a7f by fendor at 2025-08-29T11:01:36-04:00 configure: Bump minimal bootstrap GHC version to 9.10 - - - - - 716274a5 by Simon Peyton Jones at 2025-08-29T17:27:12-04:00 Fix deep subsumption again This commit fixed #26255: commit 56b32c5a2d5d7cad89a12f4d74dc940e086069d1 Author: sheaf <sam.derbyshire(a)gmail.com> Date: Mon Aug 11 15:50:47 2025 +0200 Improve deep subsumption This commit improves the DeepSubsumption sub-typing implementation in GHC.Tc.Utils.Unify.tc_sub_type_deep by being less eager to fall back to unification. But alas it still wasn't quite right for view patterns: #26331 This MR does a generalisation to fix it. A bit of a sledgehammer to crack a nut, but nice. * Add a field `ir_inst :: InferInstFlag` to `InferResult`, where ``` data InferInstFlag = IIF_Sigma | IIF_ShallowRho | IIF_DeepRho ``` * The flag says exactly how much `fillInferResult` should instantiate before filling the hole. * We can also use this to replace the previous very ad-hoc `tcInferSigma` that was used to implement GHCi's `:type` command. - - - - - 27206c5e by sheaf at 2025-08-29T17:28:14-04:00 Back-compat for TH SpecialiseP data-con of Pragma This commit improves the backwards-compatibility story for the SpecialiseP constructor of the Template Haskell 'Pragma' datatype. Instead of keeping the constructor but deprecating it, this commit makes it into a bundled pattern synonym of the Pragma datatype. We no longer deprecate it; it's useful for handling old-form specialise pragmas. - - - - - 26dbcf61 by fendor at 2025-08-30T05:10:08-04:00 Move stack decoding logic from ghc-heap to ghc-internal The stack decoding logic in `ghc-heap` is more sophisticated than the one currently employed in `CloneStack`. We want to use the stack decoding implementation from `ghc-heap` in `base`. We cannot simply depend on `ghc-heap` in `base` due do bootstrapping issues. Thus, we move the code that is necessary to implement stack decoding to `ghc-internal`. This is the right location, as we don't want to add a new API to `base`. Moving the stack decoding logic and re-exposing it in ghc-heap is insufficient, though, as we have a dependency cycle between. * ghc-heap depends on stage1:ghc-internal * stage0:ghc depends on stage0:ghc-heap To fix this, we remove ghc-heap from the set of `stage0` dependencies. This is not entirely straight-forward, as a couple of boot dependencies, such as `ghci` depend on `ghc-heap`. Luckily, the boot compiler of GHC is now >=9.10, so we can migrate `ghci` to use `ghc-internal` instead of `ghc-heap`, which already exports the relevant modules. However, we cannot 100% remove ghc's dependency on `ghc-heap`, since when we compile `stage0:ghc`, `stage1:ghc-internal` is not yet available. Thus, when we compile with the boot-compiler, we still depend on an older version of `ghc-heap`, and only use the modules from `ghc-internal`, if the `ghc-internal` version is recent enough. ------------------------- Metric Increase: T24602_perf_size T25046_perf_size_gzip T25046_perf_size_unicode T25046_perf_size_unicode_gzip size_hello_artifact size_hello_artifact_gzip size_hello_unicode size_hello_unicode_gzip ------------------------- These metric increases are unfortunate, they are most likely caused by the larger (literally in terms of lines of code) stack decoder implementation that are now linked into hello-word binaries. On linux, it is almost a 10% increase, which is considerable. - - - - - bd80bb70 by fendor at 2025-08-30T05:10:08-04:00 Implement `decode` in terms of `decodeStackWithIpe` Uses the more efficient stack decoder implementation. - - - - - 24441165 by fendor at 2025-08-30T05:10:08-04:00 Remove stg_decodeStackzh - - - - - fb9cc882 by Simon Peyton Jones at 2025-08-30T05:10:51-04:00 Fix a long standing bug in the coercion optimiser We were mis-optimising ForAllCo, leading to #26345 Part of the poblem was the tricky tower of abstractions leading to the dreadful GHC.Core.TyCo.Subst.substForAllCoTyVarBndrUsing This function was serving two masters: regular substitution, but also coercion optimsation. So tricky was it that it did so wrong. In this MR I locate all the fancy footwork for coercion optimisation in GHC.Core.Coercion.Opt, where it belongs. That leaves substitution free to be much simpler. - - - - - 6c78de2d by Sylvain Henry at 2025-09-01T08:46:19-04:00 Driver: substitute virtual Prim module in --make mode too When we build ghc-internal with --make (e.g. with cabal-install), we need to be careful to substitute the virtual interface file for GHC.Internal.Prim: - after code generation (we generate code for an empty module, so we get an empty interface) - when we try to reload its .hi file - - - - - 26e0db16 by fendor at 2025-09-01T08:47:01-04:00 Expose Stack Annotation frames in IPE backtraces by default When decoding the Haskell-native call stack and displaying the IPE information for the stack frames, we print the `StackAnnotation` of the `AnnFrame` by default. This means, when an exception is thrown, any intermediate stack annotations will be displayed in the `IPE Backtrace`. Example backtrace: ``` Exception: ghc-internal:GHC.Internal.Exception.ErrorCall: Oh no! IPE backtrace: annotateCallStackIO, called at app/Main.hs:48:10 in backtrace-0.1.0.0-inplace-server:Main annotateCallStackIO, called at app/Main.hs:46:13 in backtrace-0.1.0.0-inplace-server:Main Main.handler (app/Main.hs:(46,1)-(49,30)) Main.liftIO (src/Servant/Server/Internal/Handler.hs:30:36-42) Servant.Server.Internal.Delayed.runHandler' (src/Servant/Server/Internal/Handler.hs:27:31-41) Control.Monad.Trans.Resource.runResourceT (./Control/Monad/Trans/Resource.hs:(192,14)-(197,18)) Network.Wai.Handler.Warp.HTTP1.processRequest (./Network/Wai/Handler/Warp/HTTP1.hs:195:20-22) Network.Wai.Handler.Warp.HTTP1.processRequest (./Network/Wai/Handler/Warp/HTTP1.hs:(195,5)-(203,31)) Network.Wai.Handler.Warp.HTTP1.http1server.loop (./Network/Wai/Handler/Warp/HTTP1.hs:(141,9)-(157,42)) HasCallStack backtrace: error, called at app/Main.hs:48:32 in backtrace-0.1.0.0-inplace-server:Main ``` The first two entries have been added by `annotateCallStackIO`, defined in `annotateCallStackIO`. - - - - - a1567efd by Sylvain Henry at 2025-09-01T23:01:35-04:00 RTS: rely less on Hadrian for flag setting (#25843) Hadrian used to pass -Dfoo command-line flags directly to build the rts. We can replace most of these flags with CPP based on cabal flags. It makes building boot libraries with cabal-install simpler (cf #25843). - - - - - ca5b0283 by Sergey Vinokurov at 2025-09-01T23:02:23-04:00 Remove unnecessary irrefutable patterns from Bifunctor instances for tuples Implementation of https://github.com/haskell/core-libraries-committee/issues/339 Metric Decrease: mhu-perf - - - - - 2da84b7a by sheaf at 2025-09-01T23:03:23-04:00 Only use active rules when simplifying rule RHSs When we are simplifying the RHS of a rule, we make sure to only apply rewrites from rules that are active throughout the original rule's range of active phases. For example, if a rule is always active, we only fire rules that are themselves always active when simplifying the RHS. Ditto for inline activations. This is achieved by setting the simplifier phase to a range of phases, using the new SimplPhaseRange constructor. Then: 1. When simplifying the RHS of a rule, or of a stable unfolding, we set the simplifier phase to a range of phases, computed from the activation of the RULE/unfolding activation, using the function 'phaseFromActivation'. The details are explained in Note [What is active in the RHS of a RULE?] in GHC.Core.Opt.Simplify.Utils. 2. The activation check for other rules and inlinings is then: does the activation of the other rule/inlining cover the whole phase range set in sm_phase? This continues to use the 'isActive' function, which now accounts for phase ranges. On the way, this commit also moves the exact-print SourceText annotation from the Activation datatype to the ActivationAnn type. This keeps the main Activation datatype free of any extra cruft. Fixes #26323 - - - - - 79816cc4 by Rodrigo Mesquita at 2025-09-02T12:19:59-04:00 cleanup: Move dehydrateCgBreakInfo to Stg2Bc This no longer has anything to do with Core. - - - - - 53da94ff by Rodrigo Mesquita at 2025-09-02T12:19:59-04:00 rts/Disassembler: Fix spacing of BRK_FUN - - - - - 08c0cf85 by Rodrigo Mesquita at 2025-09-02T12:19:59-04:00 debugger: Fix bciPtr in Step-out We need to use `BCO_NEXT` to move bciPtr to ix=1, because ix=0 points to the instruction itself! I do not understand how this didn't crash before. - - - - - e7e021fa by Rodrigo Mesquita at 2025-09-02T12:19:59-04:00 debugger: Allow BRK_FUNs to head case continuation BCOs When we start executing a BCO, we may want to yield to the scheduler: this may be triggered by a heap/stack check, context switch, or a breakpoint. To yield, we need to put the stack in a state such that when execution is resumed we are back to where we yielded from. Previously, a BKR_FUN could only head a function BCO because we only knew how to construct a valid stack for yielding from one -- simply add `apply_interp_info` + the BCO to resume executing. This is valid because the stack at the start of run_BCO is headed by that BCO's arguments. However, in case continuation BCOs (as per Note [Case continuation BCOs]), we couldn't easily reconstruct a valid stack that could be resumed because we dropped too soon the stack frames regarding the value returned (stg_ret) and received (stg_ctoi) by that continuation. This is especially tricky because of the variable type and size return frames (e.g. pointer ret_p/ctoi_R1p vs a tuple ret_t/ctoi_t2). The trick to being able to yield from a BRK_FUN at the start of a case cont BCO is to stop removing the ret frame headers eagerly and instead keep them until the BCO starts executing. The new layout at the start of a case cont. BCO is described by the new Note [Stack layout when entering run_BCO]. Now, we keep the ret_* and ctoi_* frames when entering run_BCO. A BRK_FUN is then executed if found, and the stack is yielded as-is with the preserved ret and ctoi frames. Then, a case cont BCO's instructions always SLIDE off the headers of the ret and ctoi frames, in StgToByteCode.doCase, turning a stack like | .... | +---------------+ | fv2 | +---------------+ | fv1 | +---------------+ | BCO | +---------------+ | stg_ctoi_ret_ | +---------------+ | retval | +---------------+ | stg_ret_..... | +---------------+ into | .... | +---------------+ | fv2 | +---------------+ | fv1 | +---------------+ | retval | +---------------+ for the remainder of the BCO. Moreover, this more uniform approach of keeping the ret and ctoi frames means we need less ad-hoc logic concerning the variable size of ret_tuple vs ret_p/np frames in the code generator and interpreter: Always keep the return to cont. stack intact at the start of run_BCO, and the statically generated instructions will take care of adjusting it. Unlocks BRK_FUNs at the start of case cont. BCOs which will enable a better user-facing step-out (#26042) which is free of the bugs the current BRK_ALTS implementation suffers from (namely, using BRK_FUN rather than BRK_ALTS in a case cont. means we'll never accidentally end up in a breakpoint "deeper" than the continuation, because we stop at the case cont itself rather than on the first breakpoint we evaluate after it). - - - - - ade3c1e6 by Rodrigo Mesquita at 2025-09-02T12:19:59-04:00 BRK_FUN with InternalBreakLocs for code-generation time breakpoints At the start of a case continuation BCO, place a BRK_FUN. This BRK_FUN uses the new "internal breakpoint location" -- allowing us to come up with a valid source location for this breakpoint that is not associated with a source-level tick. For case continuation BCOs, we use the last tick seen before it as the source location. The reasoning is described in Note [Debugger: Stepout internal break locs]. Note how T26042c, which was broken because it displayed the incorrect behavior of the previous step out when we'd end up at a deeper level than the one from which we initiated step-out, is now fixed. As of this commit, BRK_ALTS is now dead code and is thus dropped. Note [Debugger: Stepout internal break locs] ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Step-out tells the interpreter to run until the current function returns to where it was called from, and stop there. This is achieved by enabling the BRK_FUN found on the first RET_BCO frame on the stack (See [Note Debugger: Step-out]). Case continuation BCOs (which select an alternative branch) must therefore be headed by a BRK_FUN. An example: f x = case g x of <--- end up here 1 -> ... 2 -> ... g y = ... <--- step out from here - `g` will return a value to the case continuation BCO in `f` - The case continuation BCO will receive the value returned from g - Match on it and push the alternative continuation for that branch - And then enter that alternative. If we step-out of `g`, the first RET_BCO on the stack is the case continuation of `f` -- execution should stop at its start, before selecting an alternative. (One might ask, "why not enable the breakpoint in the alternative instead?", because the alternative continuation is only pushed to the stack *after* it is selected by the case cont. BCO) However, the case cont. BCO is not associated with any source-level tick, it is merely the glue code which selects alternatives which do have source level ticks. Therefore, we have to come up at code generation time with a breakpoint location ('InternalBreakLoc') to display to the user when it is stopped there. Our solution is to use the last tick seen just before reaching the case continuation. This is robust because a case continuation will thus always have a relevant breakpoint location: - The source location will be the last source-relevant expression executed before the continuation is pushed - So the source location will point to the thing you've just stepped out of - Doing :step-local from there will put you on the selected alternative (which at the source level may also be the e.g. next line in a do-block) Examples, using angle brackets (<<...>>) to denote the breakpoint span: f x = case <<g x>> {- step in here -} of 1 -> ... 2 -> ...> g y = <<...>> <--- step out from here ... f x = <<case g x of <--- end up here, whole case highlighted 1 -> ... 2 -> ...>> doing :step-local ... f x = case g x of 1 -> <<...>> <--- stop in the alternative 2 -> ... A second example based on T26042d2, where the source is a do-block IO action, optimised to a chain of `case expressions`. main = do putStrLn "hello1" <<f>> <--- step-in here putStrLn "hello3" putStrLn "hello4" f = do <<putStrLn "hello2.1">> <--- step-out from here putStrLn "hello2.2" ... main = do putStrLn "hello1" <<f>> <--- end up here again, the previously executed expression putStrLn "hello3" putStrLn "hello4" doing step/step-local ... main = do putStrLn "hello1" f <<putStrLn "hello3">> <--- straight to the next line putStrLn "hello4" Finishes #26042 - - - - - c66910c0 by Rodrigo Mesquita at 2025-09-02T12:19:59-04:00 debugger: Re-use the last BreakpointId whole in step-out Previously, to come up with a location to stop at for `:stepout`, we would store the location of the last BreakpointId surrounding the continuation, as described by Note [Debugger: Stepout internal break locs]. However, re-using just the location from the last source breakpoint isn't sufficient to provide the necessary information in the break location. Specifically, it wouldn't bind any variables at that location. Really, there is no reason not to re-use the last breakpoint wholesale, and re-use all the information we had there. Step-out should behave just as if we had stopped at the call, but s.t. continuing will not re-execute the call. This commit updates the CgBreakInfo to always store a BreakpointId, be it the original one or the one we're emulating (for step-out). It makes variable bindings on :stepout work - - - - - e4abed7b by sheaf at 2025-09-02T12:20:40-04:00 Revert accidental changes to hie.yaml - - - - - 003b715b by meooow25 at 2025-09-02T23:48:51+02:00 Adjust the strictness of Data.List.iterate' * Don't force the next element in advance when generating a (:). * Force the first element to WHNF like every other element. Now every element in the output list is forced to WHNF when the (:) containing it is forced. CLC proposal: https://github.com/haskell/core-libraries-committee/issues/335 - - - - - b2f6aad0 by Simon Hengel at 2025-09-03T04:36:10-04:00 Refactoring: More consistently use logOutput, logInfo, fatalErrorMsg - - - - - 60a16db7 by Rodrigo Mesquita at 2025-09-03T10:55:50+01:00 bytecode: Don't PUSH_L 0; SLIDE 1 1 While looking through bytecode I noticed a quite common unfortunate pattern: ... PUSH_L 0 SLIDE 1 1 We do this often by generically constructing a tail call from a function atom that may be somewhere arbitrary on the stack. However, for the special case that the function can be found directly on top of the stack, as part of the arguments, it's plain redundant to push then slide it. In this commit we add a small optimisation to the generation of tailcalls in bytecode. Simply: lookahead for the function in the stack. If it is the first thing on the stack and it is part of the arguments which would be dropped as we entered the tail call, then don't push then slide it. In a simple example (T26042b), this already produced a drastic improvement in generated code (left is old, right is with this patch): ```diff 3c3 < 2025-07-29 10:14:02.081277 UTC --- > 2025-07-29 10:50:36.560949 UTC 160,161c160 < PUSH_L 0 < SLIDE 1 2 --- > SLIDE 1 1 164,165d162 < PUSH_L 0 < SLIDE 1 1 175,176c172 < PUSH_L 0 < SLIDE 1 2 --- > SLIDE 1 1 179,180d174 < PUSH_L 0 < SLIDE 1 1 206,207d199 < PUSH_L 0 < SLIDE 1 1 210,211d201 < PUSH_L 0 < SLIDE 1 1 214,215d203 < PUSH_L 0 < SLIDE 1 1 218,219d205 < PUSH_L 0 < SLIDE 1 1 222,223d207 < PUSH_L 0 < SLIDE 1 1 ... 600,601c566 < PUSH_L 0 < SLIDE 1 2 --- > SLIDE 1 1 604,605d568 < PUSH_L 0 < SLIDE 1 1 632,633d594 < PUSH_L 0 < SLIDE 1 1 636,637d596 < PUSH_L 0 < SLIDE 1 1 640,641d598 < PUSH_L 0 < SLIDE 1 1 644,645d600 < PUSH_L 0 < SLIDE 1 1 648,649d602 < PUSH_L 0 < SLIDE 1 1 652,653d604 < PUSH_L 0 < SLIDE 1 1 656,657d606 < PUSH_L 0 < SLIDE 1 1 660,661d608 < PUSH_L 0 < SLIDE 1 1 664,665d610 < PUSH_L 0 < SLIDE 1 1 ``` I also compiled lib:Cabal to bytecode and counted the number of bytecode lines with `find dist-newstyle -name "*.dump-BCOs" -exec wc {} +`: with unoptimized core: 1190689 lines (before) - 1172891 lines (now) = 17798 less redundant instructions (-1.5% lines) with optimized core: 1924818 lines (before) - 1864836 lines (now) = 59982 less redundant instructions (-3.1% lines) - - - - - 8b2c72c0 by L0neGamer at 2025-09-04T06:32:03-04:00 Add Control.Monad.thenM and Control.Applicative.thenA - - - - - 39e1b7cb by Teo Camarasu at 2025-09-04T06:32:46-04:00 ghc-internal: invert dependency of GHC.Internal.TH.Syntax on Data.Data This means that Data.Data no longer blocks building TH.Syntax, which allows greater parallelism in our builds. We move the Data.Data.Data instances to Data.Data. Quasi depends on Data.Data for one of its methods, so, we split the Quasi/Q, etc definition out of GHC.Internal.TH.Syntax into its own module. This has the added benefit of splitting up this quite large module. Previously TH.Syntax was a bottleneck when compiling ghc-internal. Now it is less of a bottle-neck and is also slightly quicker to compile (since it no longer contains these instances) at the cost of making Data.Data slightly more expensive to compile. TH.Lift which depends on TH.Syntax can also compile quicker and no longer blocks ghc-internal finishing to compile. Resolves #26217 ------------------------- Metric Decrease: MultiLayerModulesTH_OneShot T13253 T21839c T24471 Metric Increase: T12227 ------------------------- - - - - - bdf82fd2 by Teo Camarasu at 2025-09-04T06:32:46-04:00 compiler: delete unused names in Builtins.Names.TH returnQ and bindQ are no longer used in the compiler. There was also a very old comment that referred to them that I have modernized - - - - - 41a448e5 by Ben Gamari at 2025-09-04T19:21:43-04:00 hadrian: Pass lib & include directories to ghc `Setup configure` - - - - - 46bb9a79 by Ben Gamari at 2025-09-04T19:21:44-04:00 rts/IPE: Fix compilation when zstd is enabled This was broken by the refactoring undertaken in c80dd91c0bf6ac034f0c592f16c548b9408a8481. Closes #26312. - - - - - 138a6e34 by sheaf at 2025-09-04T19:22:46-04:00 Make mkCast assertion a bit clearer This commit changes the assertion message that gets printed when one calls mkCast with a coercion whose kind does not match the type of the inner expression. I always found the assertion message a bit confusing, as it didn't clearly state what exactly was the error. - - - - - 9d626be1 by sheaf at 2025-09-04T19:22:46-04:00 Simplifier/rules: fix mistakes in Notes & comments - - - - - 8db4d192 by Simon Hengel at 2025-09-05T06:58:49+07:00 Rename MCDiagnostic to UnsafeMCDiagnostic - - - - - 7237c57f by Simon Hengel at 2025-09-05T06:58:49+07:00 Remove -ddump-json (fixes #24113) - - - - - 24f839d1 by Simon Hengel at 2025-09-05T06:58:50+07:00 Add SrcSpan to MCDiagnostic - - - - - 893f4ac0 by Simon Hengel at 2025-09-05T06:58:50+07:00 Get rid of mkLocMessage - - - - - 3ddc94c9 by Simon Hengel at 2025-09-05T06:58:50+07:00 Add Message data type - - - - - 373caf72 by Simon Hengel at 2025-09-05T06:58:50+07:00 Get rid of MessageClass - - - - - dbb155d4 by Simon Hengel at 2025-09-05T06:58:50+07:00 Remove JSON logging - - - - - 266 changed files: - .gitlab-ci.yml - compiler/GHC/Builtin/Names/TH.hs - compiler/GHC/ByteCode/Asm.hs - compiler/GHC/ByteCode/Breakpoints.hs - compiler/GHC/ByteCode/Instr.hs - compiler/GHC/ByteCode/Types.hs - compiler/GHC/Cmm/Dataflow/Label.hs - compiler/GHC/Core/Coercion.hs - compiler/GHC/Core/Coercion/Opt.hs - compiler/GHC/Core/Lint.hs - compiler/GHC/Core/Opt/Monad.hs - compiler/GHC/Core/Opt/Pipeline/Types.hs - compiler/GHC/Core/Opt/Simplify.hs - compiler/GHC/Core/Opt/Simplify/Env.hs - compiler/GHC/Core/Opt/Simplify/Inline.hs - compiler/GHC/Core/Opt/Simplify/Iteration.hs - compiler/GHC/Core/Opt/Simplify/Utils.hs - compiler/GHC/Core/Opt/SpecConstr.hs - compiler/GHC/Core/Opt/Specialise.hs - compiler/GHC/Core/Opt/WorkWrap.hs - compiler/GHC/Core/Rules.hs - compiler/GHC/Core/TyCo/Compare.hs - compiler/GHC/Core/TyCo/Subst.hs - compiler/GHC/Core/Type.hs - compiler/GHC/Core/Unify.hs - compiler/GHC/Core/Utils.hs - compiler/GHC/CoreToIface.hs - compiler/GHC/Data/IOEnv.hs - compiler/GHC/Driver/CodeOutput.hs - compiler/GHC/Driver/Config/Core/Lint.hs - compiler/GHC/Driver/Config/Core/Opt/Simplify.hs - compiler/GHC/Driver/Downsweep.hs - compiler/GHC/Driver/Env.hs - compiler/GHC/Driver/Env/Types.hs - compiler/GHC/Driver/Errors.hs - compiler/GHC/Driver/Flags.hs - compiler/GHC/Driver/Main.hs - compiler/GHC/Driver/Make.hs - compiler/GHC/Driver/Monad.hs - compiler/GHC/Driver/Pipeline.hs - compiler/GHC/Driver/Pipeline/Execute.hs - compiler/GHC/Driver/Pipeline/LogQueue.hs - compiler/GHC/Driver/Session.hs - compiler/GHC/Hs/Binds.hs - compiler/GHC/Hs/Expr.hs - compiler/GHC/HsToCore/Monad.hs - compiler/GHC/HsToCore/Quote.hs - compiler/GHC/HsToCore/Usage.hs - compiler/GHC/Iface/Load.hs - compiler/GHC/Iface/Make.hs - compiler/GHC/Iface/Recomp.hs - compiler/GHC/Iface/Recomp/Types.hs - compiler/GHC/Linker/Deps.hs - compiler/GHC/Linker/Loader.hs - compiler/GHC/Parser.y - compiler/GHC/Plugins.hs - compiler/GHC/Rename/HsType.hs - compiler/GHC/Rename/Splice.hs - compiler/GHC/Runtime/Debugger.hs - compiler/GHC/Runtime/Debugger/Breakpoints.hs - compiler/GHC/Runtime/Eval.hs - compiler/GHC/Runtime/Heap/Inspect.hs - compiler/GHC/Stg/Lint.hs - compiler/GHC/StgToByteCode.hs - compiler/GHC/Tc/Deriv/Generics.hs - compiler/GHC/Tc/Errors.hs - compiler/GHC/Tc/Gen/App.hs - compiler/GHC/Tc/Gen/Bind.hs - compiler/GHC/Tc/Gen/Expr.hs - compiler/GHC/Tc/Gen/Expr.hs-boot - compiler/GHC/Tc/Gen/Head.hs - compiler/GHC/Tc/Gen/HsType.hs - compiler/GHC/Tc/Gen/Match.hs - compiler/GHC/Tc/Gen/Pat.hs - compiler/GHC/Tc/Gen/Splice.hs - compiler/GHC/Tc/Gen/Splice.hs-boot - compiler/GHC/Tc/Module.hs - compiler/GHC/Tc/Types.hs - compiler/GHC/Tc/Types/Evidence.hs - compiler/GHC/Tc/Types/TH.hs - compiler/GHC/Tc/Utils/Monad.hs - compiler/GHC/Tc/Utils/TcMType.hs - compiler/GHC/Tc/Utils/TcType.hs - compiler/GHC/Tc/Utils/Unify.hs - compiler/GHC/ThToHs.hs - compiler/GHC/Types/Basic.hs - compiler/GHC/Types/Error.hs - compiler/GHC/Types/Id/Make.hs - compiler/GHC/Types/SourceError.hs - compiler/GHC/Unit/Finder.hs - compiler/GHC/Unit/Finder/Types.hs - compiler/GHC/Unit/Module/Deps.hs - compiler/GHC/Utils/Binary.hs - compiler/GHC/Utils/Error.hs - compiler/GHC/Utils/Logger.hs - compiler/ghc.cabal.in - configure.ac - docs/users_guide/9.16.1-notes.rst - docs/users_guide/debugging.rst - docs/users_guide/separate_compilation.rst - ghc/GHCi/UI.hs - ghc/GHCi/UI/Exception.hs - hadrian/src/Rules/ToolArgs.hs - hadrian/src/Settings/Default.hs - hadrian/src/Settings/Packages.hs - libraries/base/changelog.md - libraries/base/src/Control/Applicative.hs - libraries/base/src/Control/Monad.hs - libraries/base/src/Data/Array/Byte.hs - libraries/base/src/Data/Bifunctor.hs - libraries/base/src/Data/Fixed.hs - libraries/base/src/GHC/Stack/CloneStack.hs - + libraries/ghc-boot-th/GHC/Boot/TH/Monad.hs - libraries/ghc-boot-th/GHC/Boot/TH/Ppr.hs - libraries/ghc-boot-th/ghc-boot-th.cabal.in - libraries/ghc-experimental/src/GHC/Stack/Annotation/Experimental.hs - libraries/ghc-heap/GHC/Exts/Heap/ClosureTypes.hs - libraries/ghc-heap/GHC/Exts/Heap/Closures.hs - + libraries/ghc-heap/GHC/Exts/Heap/Constants.hs - + libraries/ghc-heap/GHC/Exts/Heap/InfoTable.hs - + libraries/ghc-heap/GHC/Exts/Heap/InfoTable/Types.hs - + libraries/ghc-heap/GHC/Exts/Heap/InfoTableProf.hs - libraries/ghc-heap/GHC/Exts/Heap/ProfInfo/Types.hs - + libraries/ghc-heap/GHC/Exts/Stack/Constants.hs - libraries/ghc-heap/GHC/Exts/Stack/Decode.hs - libraries/ghc-heap/ghc-heap.cabal.in - − libraries/ghc-heap/tests/stack-annotation/ann_frame004.stdout - libraries/ghc-heap/cbits/HeapPrim.cmm → libraries/ghc-internal/cbits/HeapPrim.cmm - libraries/ghc-heap/cbits/Stack.cmm → libraries/ghc-internal/cbits/Stack.cmm - libraries/ghc-internal/cbits/StackCloningDecoding.cmm - libraries/ghc-heap/cbits/Stack_c.c → libraries/ghc-internal/cbits/Stack_c.c - libraries/ghc-internal/ghc-internal.cabal.in - libraries/ghc-internal/jsbits/base.js - libraries/ghc-internal/src/GHC/Internal/Base.hs - libraries/ghc-internal/src/GHC/Internal/Control/Monad.hs - libraries/ghc-internal/src/GHC/Internal/Data/Data.hs - libraries/ghc-internal/src/GHC/Internal/Exception/Backtrace.hs - + libraries/ghc-internal/src/GHC/Internal/Heap/Closures.hs - libraries/ghc-heap/GHC/Exts/Heap/Constants.hsc → libraries/ghc-internal/src/GHC/Internal/Heap/Constants.hsc - libraries/ghc-heap/GHC/Exts/Heap/InfoTable.hsc → libraries/ghc-internal/src/GHC/Internal/Heap/InfoTable.hsc - libraries/ghc-heap/GHC/Exts/Heap/InfoTable/Types.hsc → libraries/ghc-internal/src/GHC/Internal/Heap/InfoTable/Types.hsc - libraries/ghc-heap/GHC/Exts/Heap/InfoTableProf.hsc → libraries/ghc-internal/src/GHC/Internal/Heap/InfoTableProf.hsc - + libraries/ghc-internal/src/GHC/Internal/Heap/ProfInfo/Types.hs - libraries/ghc-internal/src/GHC/Internal/List.hs - + libraries/ghc-internal/src/GHC/Internal/Stack/Annotation.hs - libraries/ghc-internal/src/GHC/Internal/Stack/CloneStack.hs - libraries/ghc-heap/GHC/Exts/Stack/Constants.hsc → libraries/ghc-internal/src/GHC/Internal/Stack/Constants.hsc - + libraries/ghc-internal/src/GHC/Internal/Stack/Decode.hs - libraries/ghc-internal/src/GHC/Internal/System/Posix/Internals.hs - libraries/ghc-internal/src/GHC/Internal/TH/Lib.hs - libraries/ghc-internal/src/GHC/Internal/TH/Lift.hs - + libraries/ghc-internal/src/GHC/Internal/TH/Monad.hs - libraries/ghc-internal/src/GHC/Internal/TH/Quote.hs - libraries/ghc-internal/src/GHC/Internal/TH/Syntax.hs - libraries/ghc-heap/tests/stack-annotation/Makefile → libraries/ghc-internal/tests/stack-annotation/Makefile - libraries/ghc-heap/tests/stack-annotation/TestUtils.hs → libraries/ghc-internal/tests/stack-annotation/TestUtils.hs - libraries/ghc-heap/tests/stack-annotation/all.T → libraries/ghc-internal/tests/stack-annotation/all.T - libraries/ghc-heap/tests/stack-annotation/ann_frame001.hs → libraries/ghc-internal/tests/stack-annotation/ann_frame001.hs - libraries/ghc-heap/tests/stack-annotation/ann_frame001.stdout → libraries/ghc-internal/tests/stack-annotation/ann_frame001.stdout - libraries/ghc-heap/tests/stack-annotation/ann_frame002.hs → libraries/ghc-internal/tests/stack-annotation/ann_frame002.hs - libraries/ghc-heap/tests/stack-annotation/ann_frame002.stdout → libraries/ghc-internal/tests/stack-annotation/ann_frame002.stdout - libraries/ghc-heap/tests/stack-annotation/ann_frame003.hs → libraries/ghc-internal/tests/stack-annotation/ann_frame003.hs - libraries/ghc-heap/tests/stack-annotation/ann_frame003.stdout → libraries/ghc-internal/tests/stack-annotation/ann_frame003.stdout - libraries/ghc-heap/tests/stack-annotation/ann_frame004.hs → libraries/ghc-internal/tests/stack-annotation/ann_frame004.hs - + libraries/ghc-internal/tests/stack-annotation/ann_frame004.stdout - libraries/ghci/GHCi/Message.hs - libraries/ghci/GHCi/Run.hs - libraries/ghci/GHCi/TH.hs - libraries/ghci/ghci.cabal.in - libraries/template-haskell/Language/Haskell/TH/Lib.hs - libraries/template-haskell/Language/Haskell/TH/Quote.hs - libraries/template-haskell/Language/Haskell/TH/Syntax.hs - libraries/template-haskell/changelog.md - rts/CloneStack.c - rts/CloneStack.h - rts/Disassembler.c - rts/IPE.c - rts/Interpreter.c - rts/PrimOps.cmm - rts/Profiling.c - rts/RaiseAsync.c - rts/RtsMessages.c - rts/RtsSymbols.c - rts/RtsUtils.c - rts/STM.c - rts/Trace.c - rts/include/rts/Bytecodes.h - testsuite/.gitignore - testsuite/tests/count-deps/CountDepsAst.stdout - testsuite/tests/count-deps/CountDepsParser.stdout - testsuite/tests/deriving/should_compile/T14682.stderr - testsuite/tests/deriving/should_compile/drv-empty-data.stderr - testsuite/tests/driver/T16167.stderr - − testsuite/tests/driver/T16167.stdout - testsuite/tests/driver/all.T - testsuite/tests/driver/json2.stderr - − testsuite/tests/driver/json_dump.hs - − testsuite/tests/driver/json_dump.stderr - + testsuite/tests/driver/make-prim/GHC/Internal/Prim.hs - + testsuite/tests/driver/make-prim/Makefile - + testsuite/tests/driver/make-prim/Test.hs - + testsuite/tests/driver/make-prim/Test2.hs - + testsuite/tests/driver/make-prim/all.T - testsuite/tests/ghc-api/T7478/T7478.hs - testsuite/tests/ghci.debugger/scripts/T26042b.script - testsuite/tests/ghci.debugger/scripts/T26042b.stdout - testsuite/tests/ghci.debugger/scripts/T26042c.script - testsuite/tests/ghci.debugger/scripts/T26042c.stdout - + testsuite/tests/ghci.debugger/scripts/T26042d2.hs - + testsuite/tests/ghci.debugger/scripts/T26042d2.script - + testsuite/tests/ghci.debugger/scripts/T26042d2.stdout - testsuite/tests/ghci.debugger/scripts/T26042e.stdout - testsuite/tests/ghci.debugger/scripts/T26042f.script - testsuite/tests/ghci.debugger/scripts/T26042f1.stdout - testsuite/tests/ghci.debugger/scripts/T26042f2.stdout - testsuite/tests/ghci.debugger/scripts/T26042g.stdout - testsuite/tests/ghci.debugger/scripts/all.T - testsuite/tests/interface-stability/base-exports.stdout - testsuite/tests/interface-stability/base-exports.stdout-javascript-unknown-ghcjs - testsuite/tests/interface-stability/base-exports.stdout-mingw32 - testsuite/tests/interface-stability/base-exports.stdout-ws-32 - testsuite/tests/interface-stability/ghc-experimental-exports.stdout - testsuite/tests/interface-stability/ghc-experimental-exports.stdout-mingw32 - testsuite/tests/interface-stability/template-haskell-exports.stdout - − testsuite/tests/lib/stm/T26028.hs - − testsuite/tests/lib/stm/T26028.stdout - − testsuite/tests/lib/stm/all.T - + testsuite/tests/patsyn/should_compile/T26331.hs - + testsuite/tests/patsyn/should_compile/T26331a.hs - testsuite/tests/patsyn/should_compile/all.T - testsuite/tests/perf/compiler/T4007.stdout - testsuite/tests/plugins/hooks-plugin/Hooks/LogPlugin.hs - testsuite/tests/plugins/plugins10.stdout - testsuite/tests/profiling/should_run/callstack001.stdout - testsuite/tests/rts/all.T - testsuite/tests/simplCore/should_compile/T15056.stderr - testsuite/tests/simplCore/should_compile/T15445.stderr - + testsuite/tests/simplCore/should_compile/T26323b.hs - testsuite/tests/simplCore/should_compile/all.T - + testsuite/tests/simplCore/should_run/T26323.hs - + testsuite/tests/simplCore/should_run/T26323.stdout - testsuite/tests/simplCore/should_run/all.T - testsuite/tests/splice-imports/SI29.stderr - testsuite/tests/th/Makefile - testsuite/tests/th/T11452.stderr - testsuite/tests/th/T15321.stderr - testsuite/tests/th/T7276.stderr - + testsuite/tests/th/TH_Depends_Dir.hs - + testsuite/tests/th/TH_Depends_Dir.stdout - + testsuite/tests/th/TH_Depends_Dir_External.hs - testsuite/tests/th/TH_NestedSplicesFail3.stderr - testsuite/tests/th/TH_NestedSplicesFail4.stderr - testsuite/tests/th/all.T - + testsuite/tests/typecheck/should_compile/T26345.hs - + testsuite/tests/typecheck/should_compile/T26346.hs - + testsuite/tests/typecheck/should_compile/T26350.hs - + testsuite/tests/typecheck/should_compile/T26358.hs - testsuite/tests/typecheck/should_compile/all.T - + testsuite/tests/typecheck/should_fail/T26318.hs - + testsuite/tests/typecheck/should_fail/T26318.stderr - testsuite/tests/typecheck/should_fail/all.T - utils/check-exact/ExactPrint.hs - utils/check-exact/Main.hs - utils/check-exact/Preprocess.hs - utils/haddock/haddock-api/src/Haddock/Backends/Hyperlinker/Parser.hs - utils/jsffi/dyld.mjs The diff was not included because it is too large. View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/71d60bcdde4399e5f1bae23168349e… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/71d60bcdde4399e5f1bae23168349e… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/marge_bot_batch_merge_job] 8 commits: hadrian: Pass lib & include directories to ghc `Setup configure`
by Marge Bot (＠marge-bot) 04 Sep '25

04 Sep '25

Marge Bot pushed to branch wip/marge_bot_batch_merge_job at Glasgow Haskell Compiler / GHC Commits: 41a448e5 by Ben Gamari at 2025-09-04T19:21:43-04:00 hadrian: Pass lib & include directories to ghc `Setup configure` - - - - - 46bb9a79 by Ben Gamari at 2025-09-04T19:21:44-04:00 rts/IPE: Fix compilation when zstd is enabled This was broken by the refactoring undertaken in c80dd91c0bf6ac034f0c592f16c548b9408a8481. Closes #26312. - - - - - 138a6e34 by sheaf at 2025-09-04T19:22:46-04:00 Make mkCast assertion a bit clearer This commit changes the assertion message that gets printed when one calls mkCast with a coercion whose kind does not match the type of the inner expression. I always found the assertion message a bit confusing, as it didn't clearly state what exactly was the error. - - - - - 9d626be1 by sheaf at 2025-09-04T19:22:46-04:00 Simplifier/rules: fix mistakes in Notes & comments - - - - - ac3fe924 by Simon Peyton Jones at 2025-09-04T19:55:46-04:00 Refactor ForAllCo This is a pure refactor, addressing #26389. It arranges that the kind coercion in a ForAllCo is a MCoercion, rather than a plain Coercion, thus removing redundancy in the common case. See (FC8) in Note [ForAllCo] It's a nice cleanup. - - - - - 50193ea7 by sheaf at 2025-09-04T19:55:51-04: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 - - - - - 56046eac by sheaf at 2025-09-04T19:55:55-04:00 Revert "Remove hptAllFamInstances usage during upsweep" This reverts commit 3bf6720eff5e86e673568e756161e6d6150eb440. - - - - - 8358ec60 by soulomoon at 2025-09-04T19:55:55-04:00 Family consistency checks: add test for #26154 This commit adds the test T26154, to make sure that GHC doesn't crash when performing type family consistency checks. This test case was extracted from Agda. Fixes #26154 - - - - - 41 changed files: - compiler/GHC/Core/Coercion.hs - compiler/GHC/Core/Coercion.hs-boot - compiler/GHC/Core/Coercion/Opt.hs - compiler/GHC/Core/Lint.hs - compiler/GHC/Core/Opt/Arity.hs - compiler/GHC/Core/Opt/Simplify.hs - compiler/GHC/Core/Opt/SpecConstr.hs - compiler/GHC/Core/Reduction.hs - compiler/GHC/Core/Rules.hs - compiler/GHC/Core/TyCo/FVs.hs - compiler/GHC/Core/TyCo/Rep.hs - compiler/GHC/Core/TyCo/Subst.hs - compiler/GHC/Core/TyCo/Tidy.hs - compiler/GHC/Core/Type.hs - compiler/GHC/Core/Unify.hs - compiler/GHC/Core/Utils.hs - compiler/GHC/CoreToIface.hs - compiler/GHC/Driver/Env.hs - compiler/GHC/Iface/Rename.hs - compiler/GHC/Iface/Syntax.hs - compiler/GHC/Iface/Type.hs - compiler/GHC/IfaceToCore.hs - compiler/GHC/Tc/Instance/Family.hs - compiler/GHC/Tc/Module.hs - compiler/GHC/Tc/TyCl/Utils.hs - compiler/GHC/Tc/Utils/TcMType.hs - compiler/GHC/Tc/Utils/TcType.hs - compiler/GHC/Tc/Utils/Unify.hs - compiler/GHC/Types/Id/Make.hs - compiler/GHC/Unit/Home/Graph.hs - compiler/GHC/Unit/Home/PackageTable.hs - hadrian/src/Settings/Packages.hs - rts/IPE.c - testsuite/tests/simplCore/should_compile/OpaqueNoCastWW.stderr - + testsuite/tests/typecheck/should_compile/T26154.hs - + testsuite/tests/typecheck/should_compile/T26154_A.hs - + testsuite/tests/typecheck/should_compile/T26154_B.hs - + testsuite/tests/typecheck/should_compile/T26154_B.hs-boot - + testsuite/tests/typecheck/should_compile/T26154_Other.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/e07a72f788667a022c442bfc1b3e0b… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/compare/e07a72f788667a022c442bfc1b3e0b… You're receiving this email because of your account on gitlab.haskell.org.

1 0