- ghc-commits - Haskell.org

[Git][ghc/ghc] Pushed new branch wip/27370
by Zubin (＠wz1000) 11 Jun '26

11 Jun '26

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

1 0

[Git][ghc/ghc][wip/sjakobi/multi-caret] Shorten another comment, as suggested by @sheaf
by Simon Jakobi (＠sjakobi) 11 Jun '26

11 Jun '26

Simon Jakobi pushed to branch wip/sjakobi/multi-caret at Glasgow Haskell Compiler / GHC Commits: 99d0a9f9 by Simon Jakobi at 2026-06-11T09:33:10+00:00 Shorten another comment, as suggested by @sheaf - - - - - 1 changed file: - compiler/GHC/Tc/Errors/Types.hs Changes: ===================================== compiler/GHC/Tc/Errors/Types.hs ===================================== @@ -4131,12 +4131,7 @@ data TcRnMessage where TcRnBindingNameConflict :: !RdrName -- ^ The conflicting name -> !(NE.NonEmpty SrcSpan) -- ^ The locations of the duplicates, in ascending - -- source order. The last one is the primary span - -- of the message; 'diagnosticRelatedLocations' - -- returns the earlier ones, omitting any that - -- coincide with the primary span. See - -- Note [Choosing the primary and related spans] - -- in GHC.Types.Error. + -- source order. -> TcRnMessage {-| TcRnNonCanonicalDefinition is a warning indicating that an instance View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/99d0a9f942a09ee5847f678c29e9597… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/99d0a9f942a09ee5847f678c29e9597… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/romes/fix-test] fix: make T27131 less flaky
by Rodrigo Mesquita (＠alt-romes) 11 Jun '26

11 Jun '26

Rodrigo Mesquita pushed to branch wip/romes/fix-test at Glasgow Haskell Compiler / GHC Commits: 7bb55140 by Rodrigo Mesquita at 2026-06-11T10:27:09+01:00 fix: make T27131 less flaky It seems that T27131 fails flakily in a race where we check the flag before the capability had the chance to process the mailbox which sets the flag. This seemingly should only happen if the capability ends up being the same for setting and checking the flag. - - - - - 2 changed files: - testsuite/tests/rts/T27131.hs - testsuite/tests/rts/T27131.stdout Changes: ===================================== testsuite/tests/rts/T27131.hs ===================================== @@ -30,16 +30,22 @@ foreign import ccall unsafe "has_local_stop_after_return" main :: IO () main = do setNumCapabilities 2 - checkFlag - "TSO_STOP_NEXT_BREAKPOINT" - rts_enableStopNextBreakpoint - rts_disableStopNextBreakpoint - c_hasLocalStopNextBreakpoint - checkFlag - "TSO_STOP_AFTER_RETURN" - rts_enableStopAfterReturn - rts_disableStopAfterReturn - c_hasLocalStopAfterReturn + -- Bind to capability 0 so it can't float between capabilities while the + -- target thread runs on capability 1. + doneVar <- newEmptyMVar + _ <- forkOn 0 $ do + checkFlag + "TSO_STOP_NEXT_BREAKPOINT" + rts_enableStopNextBreakpoint + rts_disableStopNextBreakpoint + c_hasLocalStopNextBreakpoint + checkFlag + "TSO_STOP_AFTER_RETURN" + rts_enableStopAfterReturn + rts_disableStopAfterReturn + c_hasLocalStopAfterReturn + putMVar doneVar () + takeMVar doneVar checkFlag :: String @@ -58,6 +64,7 @@ checkFlag label enable disable isMyThreadFlagSet = do ThreadId tid# <- forkOn 1 $ do replicateM_ 2 $ do replyVar <- takeMVar targetCheckVar + yield -- make sure we reprocess the mailbox isSet <- (/= 0) <$> isMyThreadFlagSet putMVar replyVar isSet ===================================== testsuite/tests/rts/T27131.stdout ===================================== @@ -1,6 +1,6 @@ -(0,False) +(0,True) TSO_STOP_NEXT_BREAKPOINT set: ok TSO_STOP_NEXT_BREAKPOINT unset: ok -(0,False) +(0,True) TSO_STOP_AFTER_RETURN set: ok TSO_STOP_AFTER_RETURN unset: ok View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/7bb5514009bf8e5df6962cefc4a03c6… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/7bb5514009bf8e5df6962cefc4a03c6… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/sjakobi/multi-caret] Shorten some comments as suggested by @sheaf.
by Simon Jakobi (＠sjakobi) 11 Jun '26

11 Jun '26

Simon Jakobi pushed to branch wip/sjakobi/multi-caret at Glasgow Haskell Compiler / GHC Commits: 9591c80d by Simon Jakobi at 2026-06-11T09:22:32+00:00 Shorten some comments as suggested by @sheaf. - - - - - 4 changed files: - compiler/GHC/Tc/Errors/Ppr.hs - compiler/GHC/Tc/Errors/Types.hs - compiler/GHC/Types/Error.hs - compiler/GHC/Utils/Logger.hs Changes: ===================================== compiler/GHC/Tc/Errors/Ppr.hs ===================================== @@ -3764,13 +3764,8 @@ instance Diagnostic TcRnMessage where TcRnZonkerMessage{} -> [] -- | The prior occurrences of a duplicated entity, for use as the related --- locations of a \"duplicate\" diagnostic. Given all occurrences in ascending --- source order with the primary span last, return the earlier ones, omitting --- repeated spans and spans that coincide with the primary. Several --- occurrences can share a single span -- e.g. duplicate declarations brought --- into being by one TH splice -- and repeating the primary span among the --- related locations would draw its caret twice and emit it again in the JSON --- relatedSpans field. +-- locations of a \"duplicate\" diagnostic. +-- -- See Note [Choosing the primary and related spans] in GHC.Types.Error. priorOccurrences :: NE.NonEmpty SrcSpan -> [SrcSpan] priorOccurrences locs = ===================================== compiler/GHC/Tc/Errors/Types.hs ===================================== @@ -3981,13 +3981,7 @@ data TcRnMessage where TcRnDuplicateDecls :: !OccName -- ^ The name of the declarations -> !(NE.NonEmpty Name) -- ^ The individual declarations, in ascending source - -- order. The last one is the primary span of the - -- message; 'diagnosticRelatedLocations' returns the - -- earlier ones, omitting any that coincide with the - -- primary span (all occurrences can share one span, - -- e.g. when spliced by a single TH splice). See - -- Note [Choosing the primary and related spans] - -- in GHC.Types.Error. + -- order. -> TcRnMessage {-| TcRnPackageImportsDisabled is an error indicating that an import uses ===================================== compiler/GHC/Types/Error.hs ===================================== @@ -258,30 +258,14 @@ which GHC's diagnostics are forwarded by HLS: an LSP diagnostic carries a single https://microsoft.github.io/language-server-protocol/specifications/lsp/3.1… -How the locations are rendered: - - * Related spans are additional to the primary span, not replacements for it. - The spans that receive a caret are @primary :| relatedLocations@ (see - 'GHC.Driver.Errors.printMessage' and 'defaultLogActionWithHandles'). - - * Locations are shown — both as carets and in the @At:@ list below — in - exactly the order the message author gives them: the primary span first, - then 'diagnosticRelatedLocations' as listed. The rendering layer neither - reorders nor deduplicates. - - * Not every location can be shown as a caret: carets are optional - (@-fno-diagnostics-show-caret@), and some spans have no source to display - anyway (e.g. GHCi input or TH-generated code). Locations that get no caret - are instead listed under an @At:@ heading ('pprAtLocations'; dropped when it - would name only the primary span, which the header already states). - Every location with a real source position thus appears either as a caret - or in the @At:@ list — only spans without one ('UnhelpfulSpan') are dropped - altogether — so messages need not spell the locations out in their prose. - Carets require 'IO' to read the source, so renderers other than - 'GHC.Utils.Logger.decorateDiagnostic' — in particular the pure - 'GHC.Utils.Error.pprLocMsgEnvelope', used e.g. when 'show'ing a - 'GHC.Types.SourceError.SourceError' and for deferred type errors — list - /all/ the locations under @At:@. +Locations are rendered exactly in the order they are provided. +Not every location can be shown as a caret: + - carets are optional (@-fno-diagnostics-show-caret@) + - some spans have no source to display anyway (e.g. GHCi input or TH-generated code) + - they require 'IO' to read the source code, so pure code (e.g. 'Show SourceError') + doesn't include them. + +Locations that get no caret are instead listed under an @At:@ heading. How a message author should pick and order the spans is the subject of Note [Choosing the primary and related spans]. @@ -903,11 +887,9 @@ pprAtLocations primary spans -- | When @show_caret@ is set, render carets for the given spans; otherwise -- render nothing. Either way, return the real spans that did /not/ get a caret, --- so the caller can report those locations textually. A span is missed when --- carets are disabled, or when its source is unavailable (an unhelpful span — --- dropped here — or unreadable source such as GHCi input or TH-generated code). --- The spans are kept in the order they were given in; see Note [The source span --- model for diagnostics]. +-- so the caller can report those locations textually. +-- +-- See Note [The source span model for diagnostics]. getCaretDiagnostics :: Bool -> MessageClass -> NonEmpty SrcSpan -> IO (SDoc, [RealSrcSpan]) getCaretDiagnostics show_caret msg_class spans | not show_caret = pure (empty, realSpans) ===================================== compiler/GHC/Utils/Logger.hs ===================================== @@ -479,11 +479,7 @@ decorateDiagnostic logflags msg_class srcSpan msg = addLocations _ -> [] -- The primary span is always caret'd, with the related spans drawn as - -- additional carets. Order is the message author's: the primary first, - -- then the related spans as given. 'getCaretDiagnostics' preserves that - -- order and does not deduplicate, so an author must not repeat the primary - -- among the related spans. - -- See Note [The source span model for diagnostics] in GHC.Types.Error. + -- additional carets. See Note [The source span model for diagnostics] in GHC.Types.Error. sourceSpans :: NonEmpty SrcSpan sourceSpans = srcSpan :| relatedSpans View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/9591c80d912f90201549612ce9f27e5… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/9591c80d912f90201549612ce9f27e5… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc] Pushed new branch wip/sjakobi/T27176-clb
by Simon Jakobi (＠sjakobi2) 11 Jun '26

11 Jun '26

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

1 0

[Git][ghc/ghc] Pushed new branch wip/sjakobi/T27368
by Simon Jakobi (＠sjakobi2) 11 Jun '26

11 Jun '26

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

1 0

[Git][ghc/ghc][wip/sjakobi/clabel-monomorphic] Deleted 1 commit: Only treat continuations of reachable calls as proc points
by Simon Jakobi (＠sjakobi2) 11 Jun '26

11 Jun '26

Simon Jakobi pushed to branch wip/sjakobi/clabel-monomorphic at Glasgow Haskell Compiler / GHC WARNING: The push did not contain any new commits, but force pushed to delete the commits and changes below. Deleted commits: bf52c492 by Simon Jakobi at 2026-06-11T08:50:35+02:00 Only treat continuations of reachable calls as proc points callProcPoints used to fold over the whole block map, which can contain unreachable blocks: the control-flow optimiser and the common block eliminator both leave them behind, and they are only removed at the end of the Cmm pipeline (Note [unreachable blocks]). In particular, when CBE merges duplicated call blocks it leaves the losing copy in the block map, and the continuation of such a dead call can itself be unreachable. callProcPoints would still collect that continuation, attachContInfoTables would attach an info table to it, but stack layout (which only walks reachable blocks) produced no stack map for it, so setInfoTableStackMap panicked: ghc: panic! (the 'impossible' happened) setInfoTableStackMap This was triggered by compiling GHC.CmmToAsm.Dwarf.Types with -O2 after the previous commit reshaped the CLabel printers, but the bug is latent and independent of that change. Fix: make callProcPoints fold over revPostorder, i.e. reachable blocks only. Also correct the stale comment in elimCommonBlocks claiming that ContFlowOpt has already removed unreachable blocks, and extend Note [unreachable blocks] with the invariant and a warning that the Cmm pretty-printer hides unreachable blocks in dumps. Co-Authored-By: Claude Fable 5 <noreply(a)anthropic.com> - - - - - 3 changed files: - compiler/GHC/Cmm/CommonBlockElim.hs - compiler/GHC/Cmm/Pipeline.hs - compiler/GHC/Cmm/ProcPoint.hs Changes: ===================================== compiler/GHC/Cmm/CommonBlockElim.hs ===================================== @@ -63,10 +63,16 @@ elimCommonBlocks :: CmmGraph -> CmmGraph elimCommonBlocks g = replaceLabels env $ copyTicks env g where env = iterate mapEmpty blocks_with_key - -- The order of blocks doesn't matter here. While we could use - -- revPostorder which drops unreachable blocks this is done in - -- ContFlowOpt already which runs before this pass. So we use - -- toBlockList since it is faster. + -- The order of blocks doesn't matter here. Note that toBlockList + -- includes unreachable blocks (ContFlowOpt leaves them in the block + -- map, see Note [unreachable blocks] in GHC.Cmm.Pipeline), so we may + -- hash and merge dead blocks, and a live block may even be + -- substituted by an unreachable duplicate (resurrecting it). That is + -- semantically harmless since the blocks are identical, but it means + -- this pass both consumes and produces unreachable blocks; passes + -- between this one and the final removeUnreachableBlocksProc must + -- not let blocks that are unreachable here influence the reachable + -- part of the graph (see e.g. callProcPoints in GHC.Cmm.ProcPoint). groups = groupByInt hash_block (toBlockList g) :: [[CmmBlock]] blocks_with_key = [ [ (successors b, [b]) | b <- bs] | bs <- groups] ===================================== compiler/GHC/Cmm/Pipeline.hs ===================================== @@ -352,10 +352,22 @@ _GLOBAL_OFFSET_TABLE_, regardless of which entry point we arrived via. {- Note [unreachable blocks] ~~~~~~~~~~~~~~~~~~~~~~~~~ -The control-flow optimiser sometimes leaves unreachable blocks behind -containing junk code. These aren't necessarily a problem, but -removing them is good because it might save time in the native code -generator later. +The control-flow optimiser and the common block eliminator sometimes +leave unreachable blocks behind containing junk code; they are only +removed here, at the end of the pipeline. Removing them earlier would +cost extra reachability passes, but deferring the removal means every +pass in between runs on a block map that may contain unreachable +blocks, and must take care that they don't influence the reachable +part of the graph. In particular, the continuation of a call in an +unreachable block may itself be unreachable, so it must not be treated +as a proc point: stack layout only lays out reachable blocks, and an +info table attached (by attachContInfoTables) to a continuation +without a stack map makes setInfoTableStackMap panic. See +callProcPoints in GHC.Cmm.ProcPoint. + +Beware also that the Cmm pretty-printer omits unreachable blocks, so +they do not show up in -ddump-cmm-* output; a dump can therefore look +consistent while the underlying block map is not. -} ===================================== compiler/GHC/Cmm/ProcPoint.hs ===================================== @@ -173,8 +173,16 @@ procPointLattice = DataflowLattice unreached add_to -- introduced because they're reachable from multiple proc points. -- -- Extract the set of Continuation BlockIds, see Note [Continuation BlockIds]. +-- +-- We must consider only *reachable* blocks: the common block eliminator +-- leaves duplicated (hence unreachable) call blocks in the block map +-- (see Note [unreachable blocks] in GHC.Cmm.Pipeline), and the +-- continuation of such a dead call may itself be unreachable. Stack +-- layout only lays out reachable blocks, so a continuation collected +-- from a dead call would get an info table (attachContInfoTables) but +-- no stack map, making setInfoTableStackMap panic. callProcPoints :: CmmGraph -> ProcPointSet -callProcPoints g = foldlGraphBlocks add (setSingleton (g_entry g)) g +callProcPoints g = foldl' add (setSingleton (g_entry g)) (revPostorder g) where add :: LabelSet -> CmmBlock -> LabelSet add set b = case lastNode b of CmmCall {cml_cont = Just k} -> setInsert k set View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/bf52c49204953d0ffd2b1c5a74003f4… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/bf52c49204953d0ffd2b1c5a74003f4… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc] Pushed new branch wip/sjakobi/clabel-monomorphic
by Simon Jakobi (＠sjakobi2) 11 Jun '26

11 Jun '26

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

1 0

[Git][ghc/ghc][wip/sjakobi/testsuite-atomic-output] testsuite: Give each test's output block a header
by Simon Jakobi (＠sjakobi2) 11 Jun '26

11 Jun '26

Simon Jakobi pushed to branch wip/sjakobi/testsuite-atomic-output at Glasgow Haskell Compiler / GHC Commits: 9dc76830 by Simon Jakobi at 2026-06-11T08:45:04+02:00 testsuite: Give each test's output block a header A test's output is now emitted as one contiguous block (see Note [Atomic test output]), but adjacent blocks had no demarcation, so e.g. a one-line message from a passing test visually attached itself to a neighbouring test's failure diff. Prefix each non-empty block with a header naming the test and follow it with a blank line. Co-Authored-By: Claude Fable 5 <noreply(a)anthropic.com> - - - - - 1 changed file: - testsuite/driver/testlib.py Changes: ===================================== testsuite/driver/testlib.py ===================================== @@ -1590,6 +1590,13 @@ async def runTestAtomically(opts, name: TestName, func, args): output_buffer_ctx_var.reset(token) s = buf.getvalue() if s: + # Set the block apart from adjacent tests' output with a header + # naming the test and a trailing blank line. Without this, + # neighbouring blocks read as one interleaved mess, and output + # of passing tests cannot be attributed to its test at all. + if not s.endswith('\n'): + s += '\n' + s = '=====> output from {}:\n{}\n'.format(name, s) # The event loop is single-threaded and there is no await between # these calls, so the block is written out atomically. sys.stdout.write(s) View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/9dc76830395b1d84f032a54ed0b943e… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/9dc76830395b1d84f032a54ed0b943e… You're receiving this email because of your account on gitlab.haskell.org.

1 0

[Git][ghc/ghc][wip/sjakobi/T16720] testsuite: Colorize the failure-output summary, also in CI
by Simon Jakobi (＠sjakobi2) 11 Jun '26

11 Jun '26

Simon Jakobi pushed to branch wip/sjakobi/T16720 at Glasgow Haskell Compiler / GHC Commits: 3d1919a5 by Simon Jakobi at 2026-06-11T08:32:19+02:00 testsuite: Colorize the failure-output summary, also in CI Make the per-test blocks in the "Output of unexpected failures" section easier to scan: * the '=====> test(way) [reason]' header is red, * the 'Captured stdout/stderr:' labels are cyan, * the captured output itself is indented four spaces. Colors were previously disabled in CI because the driver only emits them when stdout is a tty, yet the GitLab log viewer renders ANSI colors fine. Add a --force-colors driver flag and pass it from .gitlab/ci.sh. Note that config.supports_colors stays tty-based, since it also guards terminal-title escape sequences, which must not end up in a CI log. The SUMMARY header and the new section now honor summary()'s color parameter, so the plain-text summary file no longer receives escape codes when colors are enabled. Co-Authored-By: Claude Fable 5 <noreply(a)anthropic.com> - - - - - 3 changed files: - .gitlab/ci.sh - testsuite/driver/runtests.py - testsuite/driver/testlib.py Changes: ===================================== .gitlab/ci.sh ===================================== @@ -644,6 +644,10 @@ function test_hadrian() { check_msys2_deps _build/stage1/bin/ghc --version check_release_build + # The GitLab log viewer renders ANSI colors, but the testsuite driver only + # emits them when stdout is a tty unless they are forced. + RUNTEST_ARGS="${RUNTEST_ARGS:-} --force-colors" + # Ensure that statically-linked builds are actually static if [[ "${BUILD_FLAVOUR}" = *static* ]]; then bad_execs="" ===================================== testsuite/driver/runtests.py ===================================== @@ -94,6 +94,8 @@ parser.add_argument("--ignore-perf-failures", choices=['increases','decreases',' help="Do not fail due to out-of-tolerance perf tests") parser.add_argument("--only-report-hadrian-deps", type=Path, help="Dry run the testsuite and report all extra hadrian dependencies needed on the given file") +parser.add_argument("--force-colors", action="store_true", + help="emit ANSI colors even when stdout is not a tty (e.g. for CI logs)") args = parser.parse_args() @@ -259,7 +261,9 @@ def supports_colors(): return True config.supports_colors = supports_colors() -term_color.enable_color = config.supports_colors +# Note that config.supports_colors deliberately stays tty-based: it also +# guards terminal-title updates, which must not end up in a CI log. +term_color.enable_color = config.supports_colors or args.force_colors # This has to come after arg parsing as the args can change the compiler get_compiler_info() @@ -587,7 +591,7 @@ else: print(Perf.allow_changes_string([(m.change, m.stat) for m in t.metrics])) print('-' * 25) - summary(t, sys.stdout, color=config.supports_colors) + summary(t, sys.stdout, color=term_color.enable_color) # Write perf stats if any exist or if a metrics file is specified. stats_metrics = [stat for (_, stat, __) in t.metrics] # type: List[PerfStat] ===================================== testsuite/driver/testlib.py ===================================== @@ -3543,7 +3543,8 @@ def summary(t: TestRun, file: TextIO, color=False) -> None: summary_color = Color.GREEN assert t.start_time is not None - file.write(colored(summary_color, 'SUMMARY') + ' for test run started at ' + summary_header = colored(summary_color, 'SUMMARY') if color else 'SUMMARY' + file.write(summary_header + ' for test run started at ' + t.start_time.strftime("%c %Z") + '\n' + str(datetime.datetime.now() - t.start_time).rjust(8) + ' spent to go through\n' @@ -3597,7 +3598,7 @@ def summary(t: TestRun, file: TextIO, color=False) -> None: if t.unexpected_failures: file.write('Output of unexpected failures:\n\n') - printTestOutputSummary(file, t.unexpected_failures) + printTestOutputSummary(file, t.unexpected_failures, color) if stopping(): file.write('WARNING: Testsuite run was terminated early\n') @@ -3616,22 +3617,27 @@ def printUnexpectedTests(file: TextIO, testInfoss): # per stream in the final summary (see printTestOutputSummary). MAX_SUMMARY_OUTPUT_LINES = 100 -def printTestOutputSummary(file: TextIO, testInfos) -> None: +def printTestOutputSummary(file: TextIO, testInfos, color: bool=False) -> None: # Repeat the captured output of failing tests at the end of the run, so # that one can see why a test failed without hunting for its output # earlier in the (possibly very long) log; see #16720. + # The captured output is indented to set it apart from the headers. for result in sorted(testInfos, key=lambda r: (r.testname.lower(), r.way, r.directory)): - file.write(colored(Color.RED, - '=====> {}({}) [{}]'.format(result.testname, result.way, result.reason)) - + '\n') + header = '=====> {}({}) [{}]'.format(result.testname, result.way, result.reason) + if color: + header = colored(Color.RED, header) + file.write(header + '\n') for stream_name, contents in [('stdout', result.stdout), ('stderr', result.stderr)]: if contents and contents.strip(): + label = 'Captured {}:'.format(stream_name) + if color: + label = colored(Color.CYAN, label) lines = contents.rstrip('\n').split('\n') if len(lines) > MAX_SUMMARY_OUTPUT_LINES: omitted = len(lines) - MAX_SUMMARY_OUTPUT_LINES lines = lines[:MAX_SUMMARY_OUTPUT_LINES] \ + ['... ({} more lines omitted, see junit.xml)'.format(omitted)] - s = 'Captured {}:\n{}\n'.format(stream_name, '\n'.join(lines)) + s = label + '\n' + ''.join(' ' + l + '\n' for l in lines) # Test output can contain characters that file's encoding # cannot represent; replace rather than crash (cf safe_print). enc = getattr(file, 'encoding', None) or 'utf-8' View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/3d1919a5194d22eb960eac3c6a44927… -- View it on GitLab: https://gitlab.haskell.org/ghc/ghc/-/commit/3d1919a5194d22eb960eac3c6a44927… You're receiving this email because of your account on gitlab.haskell.org.

1 0