Skip to content

Conversation

@bripeticca
Copy link
Contributor

@bripeticca bripeticca commented Nov 11, 2025

  • Built tentative test class SwiftBuildSystemOutputParser SwiftBuildSystemMessageHandler to handle the compiler output specifically
  • Moved emitEvent method into the SwiftBuildSystemMessageHandler
  • Selectively emit DiagnosticInfo depending on whether the flag appendToOutputStream is true.
  • OutputInfo will capture the compiler output with the code snippet + fixits, so emit diagnostics with appendToOutputStream set to false here instead

TODO:

  • Properly identify diagnostic-related output; much of the SwiftBuildMessage.OutputInfo does not pertain to diagnostic-related code snippets
  • Assess whether separation of emitEvent handling would be better-suited within the SwiftBuildSystemOutputParser; if so, to consolidate behaviour for this class
  • Tests
    • Test the SwiftBuildSystemMessageHandler for various SwiftBuildMessage types
    • Identify whether we've successfully omitted diagnostics from being emitted redundantly
  • Maybe: Identify various diagnostic output structures to correctly emit output as the expected diagnostic severity

* 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
emitInfoAsDiagnostic(info: info)
}
case .output(let info):
let parsedOutput = String(decoding: info.data, as: UTF8.self)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One consideration here: I don't think output messages are guaranteed to be split at character boundaries. So for example, we could emit two output messages, with the last byte of one message being the first byte of a 2-byte character and the second message having the second byte of that character. And then this String(decoding:) call might mangle the character.

I think it's also possible we receive something like (output message) -> (progress update message) -> (output message) which could split the output at arbitrary points.

Maybe when we receive an output message, we should append to a per-task buffer, then only decode it as a string and emit the output when the taskComplete message arrives?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, I've found this to be the case with some light local testing as well -- I'll give the per-task buffer a shot!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants