Capture code snippet from diagnostic compiler output #9362

bripeticca · 2025-11-11T17:13:25Z

This PR refactors diagnostic handling in the Swift build system by introducing a dedicated message handler and per-task output buffering to properly parse and emit compiler diagnostics individually.

Key Changes

SwiftBuildSystemMessageHandler

Introduced a new dedicated handler class to process SwiftBuildMessage events from the build operation
Moved message handling logic out of inline nested functions for better organization and testability
Maintains build state, progress animation, and diagnostic processing in a single cohesive component

Per-Task Data Buffering

Added taskDataBuffer struct in BuildState to capture compiler output per task signature
New TaskDataBuffer struct allows for using LocationContext or LocationContext2 as a subscript key to fetch the appropriate data buffer for a task, defaulting to the global buffer if no associated task or target can be identified.
Task output is accumulated in the buffer as .output messages arrive
Buffer contents are processed when tasks complete, ensuring all output is captured before parsing
Failed tasks with no useful or apparent message will be demoted to an info log level to avoid creating too much noise on the output.

* Built tentative test class SwiftBuildSystemOutputParser to handle the compiler output specifically * Added a handleDiagnostic method to possibly substitute the emitEvent local scope implementation of handling a SwiftBuildMessage diagnostic

* the flag `appendToOutputStream` helps us to determine whether a diagnostic is to be emitted or whether we'll be emitting the compiler output via OutputInfo * separate the emitEvent method into the SwiftBuildSystemMessageHandler

Sources/SwiftBuildSupport/SwiftBuildSystem.swift

bripeticca · 2025-11-20T19:08:16Z

@swift-ci please test

owenv

Thie generally lgtm but I have some concerns about the regex-based parsing when we emit the textual compiler output.

Perf - It's important this is fast so that it doesn't block the end of the build if a command produces huge quantities of output. It's hard to say if this will be a real issue without some testing
We're re-parsing information which we're already getting from the compiler in structured form. I see the appeal of not reporting a diagnostic twice if multiple compile jobs report it though

Sources/SwiftBuildSupport/SwiftBuildSystem.swift

jakepetroules · 2025-11-21T04:41:23Z

2. We're re-parsing information which we're already getting from the compiler in structured form. I see the appeal of not reporting a diagnostic twice if multiple compile jobs report it though

I also pointed this out inline, though I'm not sure why the re-parsing relates to deduplication? We should be able to deduplicate diagnostics whether we parse them again or use the existing ones.

bripeticca · 2025-11-21T16:40:20Z

though I'm not sure why the re-parsing relates to deduplication

(@jakepetroules @owenv -- tagging for visibility, GitHub notifications can be weird)

Re-parsing doesn't affect the de-duplication -- when tracking the data buffer per task, I also track whether we've emitted the associated output for a given task (using its signature) and guard against this before emitting for that task again. We only go down this path (emitting for a given task) once we've received the task completed event.

I mentioned this inline as well but for visibility: the re-parsing just addresses the fact that for a given task signature, we have an accumulated data buffer that contains all possible diagnostic messages coming from the compiler. I find that the user ergonomics aren't great when simply emitting the entire string blob through the observability scope, since these diagnostics can have varying severities and we'll have to decide up-front which severity to choose to emit the entire string of all diagnostics.

I do also maintain a list of the DiagnosticInfo that we omit in favour of emitting the OutputInfo containing the same diagnostic messages, but with the plus of having the pre-formatted code snippet (the DiagnosticInfo is missing the pre-formatted code snippet but contains enough information to recreate it ourselves, and it was suggested that we instead fall back to using the OutputInfo for that reason).

Perhaps some more discussion is needed here. 😄

* Remove taskStarted outputStream emissions * Propagate exception if unable to find path

bkhouri

This is great work, but we should also include automated tests as part of this change to ensure we won't regress the behaviour.

Sources/Basics/Observability.swift

bkhouri · 2025-12-03T14:09:38Z

Sources/Basics/Observability.swift

 public protocol DiagnosticsHandler: Sendable {
    func handleDiagnostic(scope: ObservabilityScope, diagnostic: Diagnostic)
+
+    func printToOutput(message: String)


I don't think it's the DiagnosticHandlers responsibility to print the diagnostic here. We should instead have a "LoggingHandler" which would know where to emit the "message", whether it's to stdout, stderr, to a file, or some other place.

Sources/SwiftBuildSupport/SwiftBuildSystem.swift

bkhouri · 2025-12-03T14:16:43Z

Sources/SwiftBuildSupport/SwiftBuildSystem.swift

+    /// Tracks the task IDs for failed tasks.
+    private var failedTasks: [Int] = []
+    /// Tracks the tasks by their signature for which we have already emitted output.
+    private var tasksEmitted: Set<String> = []


question (possibly-blocking): what is the difference between tasksEmitted and taskIDsEmitted? If they are tracking the same thing, can we remove one? If we need both, could you please provide an explanation?

Many taskIDs can map to a singular taskSignature, and so I initially thought it could be helpful to track both separately. However, I think simply tracking by taskSignature may be sufficient here, so I removed taskIDsEmitted in the latest change.

Many taskIDs can map to a singular taskSignature

I think that shouldn't be true within a single build operation. Are you seeing that to not be the case?

I have seen this behaviour locally, usually between two tasks that have an execution description of Emit Swift module (arm64) and Compile <filename>.swift (arm64) respectively; they'll share a task signature but have differing task IDs.

That sounds like a bug. The signatures are supposed to be globally unique.

cc @owenv

I suspect we should avoid using the signatures at all right now, and use only the numeric task IDs for safety.

In this case, these two tasks also produce the same output (particularly the diagnostics) which helped to reduce duplicate logs. I'll try some alternative approaches locally but I may have to track both ID and signature for the time being.

I created an issue to investigate this in a separate PR: #9485

* Defer emission of diagnostics to completed task event * Remove global data buffer from TaskDataBuffer * Remove emits to observabilityScope for taskStarted events * Move SwiftBuildSystemMessageHandler to its own file * Rename printToOutput to print(_ output:verbose:) * Remove unprocessedDiagnostics parameter from message handler * Remove taskIDsEmitted in favour of using tasksEmitted

Sources/SwiftBuildSupport/SwiftBuildSystemMessageHandler.swift

Modified the map to track these by targetID rather than name; since the `BuildResult` is expecting a map by targetName, another computed property representing the same map by targetName has also been added

bripeticca · 2025-12-05T20:51:50Z

@swift-ci please test

bripeticca · 2025-12-05T20:52:06Z

@swift-ci please test windows

Sources/SwiftBuildSupport/SwiftBuildSystemMessageHandler.swift

PhantomInTheWire

hey @bripeticca just a quick one do you think your changes might fix #8877?

bripeticca · 2025-12-08T17:26:08Z

@PhantomInTheWire I'll take a look and see if this addresses the issue, thanks for the heads up!

bripeticca · 2025-12-08T22:17:41Z

@swift-ci please test

bripeticca · 2025-12-08T22:18:34Z

@swift-ci please test windows

bripeticca · 2025-12-09T15:11:40Z

Errors seem unrelated to this change, re-triggering tests

@swift-ci please test linux

bripeticca · 2025-12-09T15:11:51Z

@swift-ci please test macOS

bripeticca · 2025-12-09T16:22:45Z

@swift-ci please test linux

bripeticca · 2025-12-09T20:23:35Z

@PhantomInTheWire It looks like this change will definitely affect possible solutions for #8877 , but I am skeptical that it will resolve it entirely. If you're interested in taking a look at it still, I would highly recommend doing so once this PR is merged 😄

PhantomInTheWire · 2025-12-09T21:15:28Z

sure i'll take a look once this is merged, @bripeticca

…t stream Some minor fixes to how task output is handled in the SwiftBuildSystemMessageHandler.

jakepetroules · 2025-12-10T02:11:32Z

@swift-ci test

bripeticca added 2 commits November 11, 2025 12:07

owenv reviewed Nov 12, 2025

View reviewed changes

Sources/SwiftBuildSupport/SwiftBuildSystem.swift Outdated Show resolved Hide resolved

bripeticca added 5 commits November 13, 2025 13:33

Implement per-task-buffer of Data output

b1ff231

Fallback to locationContext if locationContext2 properties are nil

ac6b81b

Merge branch 'main' into swb/diagnosticcodesnippet

1ae0f38

Cleanup; add descriptions related to redundant task output

b81bfca

attempt to parse decoded string into individual diagnostics

f3aaabf

bripeticca force-pushed the swb/diagnosticcodesnippet branch from a20f020 to f3aaabf Compare November 20, 2025 18:56

cleanup

c48e606

bripeticca force-pushed the swb/diagnosticcodesnippet branch from 1dcaaeb to c48e606 Compare November 20, 2025 18:58

bripeticca changed the title ~~[WIP] Capture code snippet from diagnostic compiler output~~ Capture code snippet from diagnostic compiler output Nov 20, 2025

bripeticca marked this pull request as ready for review November 20, 2025 19:21

bripeticca requested review from bkhouri, cmcgee1024, daveyc123, dschaefer2, jakepetroules, plemarquand and rconnell9 as code owners November 20, 2025 19:21

owenv reviewed Nov 20, 2025

View reviewed changes

Sources/SwiftBuildSupport/SwiftBuildSystem.swift Outdated Show resolved Hide resolved

Sources/SwiftBuildSupport/SwiftBuildSystem.swift Outdated Show resolved Hide resolved

Sources/SwiftBuildSupport/SwiftBuildSystem.swift Outdated Show resolved Hide resolved

jakepetroules reviewed Nov 20, 2025

View reviewed changes

Sources/SwiftBuildSupport/SwiftBuildSystem.swift Outdated Show resolved Hide resolved

jakepetroules reviewed Nov 20, 2025

View reviewed changes

Sources/SwiftBuildSupport/SwiftBuildSystem.swift Outdated Show resolved Hide resolved

jakepetroules reviewed Nov 20, 2025

View reviewed changes

Sources/SwiftBuildSupport/SwiftBuildSystem.swift Outdated Show resolved Hide resolved

jakepetroules reviewed Nov 21, 2025

View reviewed changes

Sources/SwiftBuildSupport/SwiftBuildSystem.swift Outdated Show resolved Hide resolved

bripeticca added 2 commits November 21, 2025 15:38

Revert diagnostic parsing and emit directly to outputStream

f14600c

Address PR comments

359331a

* Remove taskStarted outputStream emissions * Propagate exception if unable to find path

bkhouri requested changes Dec 3, 2025

View reviewed changes

bripeticca added 2 commits December 4, 2025 13:59

Modify test mocks using exposed memberwise inits

a658f58

jakepetroules reviewed Dec 5, 2025

View reviewed changes

Sources/SwiftBuildSupport/SwiftBuildSystemMessageHandler.swift Outdated Show resolved Hide resolved

bripeticca added 3 commits December 5, 2025 15:42

Fix check on global task for LocationContext

e88ab96

Track serialized diagnostic path by targetID

5f0911d

Modified the map to track these by targetID rather than name; since the `BuildResult` is expecting a map by targetName, another computed property representing the same map by targetName has also been added

Merge branch 'main' into swb/diagnosticcodesnippet

8f713a0

jakepetroules mentioned this pull request Dec 5, 2025

Output stream inconsistency on failed build command between build systems #8877

Open

1 task

jakepetroules reviewed Dec 5, 2025

View reviewed changes

Sources/SwiftBuildSupport/SwiftBuildSystemMessageHandler.swift Show resolved Hide resolved

PhantomInTheWire reviewed Dec 6, 2025

View reviewed changes

bripeticca added 2 commits December 8, 2025 17:16

Add FIXME + richer model to track emitted tasks

fd21a42

Merge branch 'main' into swb/diagnosticcodesnippet

7a91843

bripeticca added 4 commits December 9, 2025 12:06

Add documentation

4e29267

Merge branch 'main' into swb/diagnosticcodesnippet

45dc48c

remove old print method

f5dd65c

Merge branch 'swb/diagnosticcodesnippet' into swb/messagehandlertests

11d3945

bripeticca mentioned this pull request Dec 10, 2025

Investigate possibly incorrect SwiftBuildSystem mapping of taskSignature to taskID swiftlang/swift-build#969

Open

1 task

Create new testing observability system that can be supplied an outpu…

30fc79a

…t stream Some minor fixes to how task output is handled in the SwiftBuildSystemMessageHandler.

jakepetroules approved these changes Dec 10, 2025

View reviewed changes

Capture code snippet from diagnostic compiler output #9362

Are you sure you want to change the base?

Capture code snippet from diagnostic compiler output #9362

Conversation

bripeticca commented Nov 11, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Key Changes

Uh oh!

Uh oh!

bripeticca commented Nov 20, 2025

Uh oh!

owenv left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jakepetroules commented Nov 21, 2025

Uh oh!

bripeticca commented Nov 21, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bkhouri left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

bripeticca commented Dec 5, 2025

Uh oh!

bripeticca commented Dec 5, 2025

Uh oh!

Uh oh!

PhantomInTheWire left a comment

Choose a reason for hiding this comment

Uh oh!

bripeticca commented Dec 8, 2025

Uh oh!

bripeticca commented Dec 8, 2025

Uh oh!

bripeticca commented Dec 8, 2025

Uh oh!

bripeticca commented Dec 9, 2025

Uh oh!

bripeticca commented Dec 9, 2025

Uh oh!

bripeticca commented Dec 9, 2025

Uh oh!

bripeticca commented Dec 9, 2025

Uh oh!

PhantomInTheWire commented Dec 9, 2025

Uh oh!

jakepetroules commented Dec 10, 2025

Uh oh!

Reviewers

Assignees

Labels

bripeticca commented Nov 11, 2025 •

edited

Loading

bripeticca commented Nov 21, 2025 •

edited

Loading