Unintentional but unacceptable diagnostic language #5968
Comments
|
Almost certainly the remark refers to "whole module optimization". Seems to be two bugs:
Taking a look. |
|
I do see the missing newline, but not the cutting off, so I get I only get this if I set Still not good, so checking what's going on. |
|
Also seems unfortunate to be getting that same message so many times; either SwiftPM should dedupe or maybe that's something in the driver. In any case the missing newline seems to be the first thing to address here, and that is almost certainly on the SwiftPM side. |
|
❯ So this looks like a combination of two things:
For example: |
|
Filed swiftlang/swift-driver#1241 on the Swift Driver issue and will see what we do in SwiftPM about the current state of affairs. Since the output is always line-based, we should be able to do better in the JSON parser than we are currently doing. |
|
This is fairly reminiscent of the llbuild issue that we had on Windows - we would not buffer things correctly and interleave messages: #4192 |
|
That's a good point — thanks for pointing this out. In this case it seems that this is actually handled fairly well already by the JSON parser in SwiftPM, and an additional newline is all that's needed. That doesn't explain the truncation but does at least properly emit the diagnostics. I still think the driver should emit JSON for its own diagnostics, though, when |
|
I'm preparing a SwiftPM PR for the newline at least. |
|
rdar://103608636 |
…lines SwiftPM uses the Swift Driver's `-parseable-output` flag to get a sequence of length-prefixed JSON-encoded messages that it can read. Unfortunately the Swift Driver doesn't JSON-encode its own diagnostics, leading to things like swiftlang#5968. I filed swiftlang#5968 on the Swift Driver to get it to encode its JSON messages, but meanwhile, it turns out that we can fairly easily fix the fallback logic that SwiftPM uses when it emits raw output. It was simply missing a newline. It's safe to always add one, since the logic that parses JSON splits by newlines, so we won't find any terminating newlines. rdar://103608636
…lines SwiftPM uses the Swift Driver's `-parseable-output` flag to get a sequence of length-prefixed JSON-encoded messages that it can read. Unfortunately the Swift Driver doesn't JSON-encode its own diagnostics, leading to things like swiftlang#5968. I filed swiftlang#5968 on the Swift Driver to get it to encode its JSON messages, but meanwhile, it turns out that we can fairly easily fix the fallback logic that SwiftPM uses when it emits raw output. It was simply missing a newline. It's safe to always add a newline to the raw driver output, since the logic that parses JSON splits by newlines, so we won't find any terminating newlines. Note that we don't add newlines to the output coming from messages from the compiler frontend, since that output already has trailing newlines. rdar://103608636
…lines SwiftPM uses the Swift Driver's `-parseable-output` flag to get a sequence of length-prefixed JSON-encoded messages that it can read. Unfortunately the Swift Driver doesn't JSON-encode its own diagnostics, leading to things like swiftlang#5968. I filed swiftlang#5968 on the Swift Driver to get it to encode its JSON messages, but meanwhile, it turns out that we can fairly easily fix the fallback logic that SwiftPM uses when it emits raw output. It was simply missing a newline. It's safe to always add a newline to the raw driver output, since the logic that parses JSON splits by newlines, so we won't find any terminating newlines. Note that we don't add newlines to the output coming from messages from the compiler frontend, since that output already has trailing newlines. rdar://103608636
…lines SwiftPM uses the Swift Driver's `-parseable-output` flag to get a sequence of length-prefixed JSON-encoded messages that it can read. Unfortunately the Swift Driver doesn't JSON-encode its own diagnostics, leading to things like swiftlang#5968. I filed swiftlang#5968 on the Swift Driver to get it to encode its JSON messages, but meanwhile, it turns out that we can fairly easily fix the fallback logic that SwiftPM uses when it emits raw output. It was simply missing a newline. It's safe to always add a newline to the raw driver output, since the logic that parses JSON splits by newlines, so we won't find any terminating newlines that shouldn't be on the string. Note that we do not add newlines to the output coming from messages from the compiler frontend, since that output already has trailing newlines. So in essence this change makes the `.unparsableOutput()` case the same as the cases of regular output, from a newline perspective. rdar://103608636
…lines (#5987) SwiftPM uses the Swift Driver's `-parseable-output` flag to get a sequence of length-prefixed JSON-encoded messages that it can read. Unfortunately the Swift Driver doesn't JSON-encode its own diagnostics, leading to things like #5968. I filed #5968 on the Swift Driver to get it to encode its JSON messages, but meanwhile, it turns out that we can fairly easily fix the fallback logic that SwiftPM uses when it emits raw output. It was simply missing a newline. It's safe to always add one, since the logic that parses JSON splits by newlines, so we won't find any terminating newlines. rdar://103608636
…ng newlines (swiftlang#5987) SwiftPM uses the Swift Driver's `-parseable-output` flag to get a sequence of length-prefixed JSON-encoded messages that it can read. Unfortunately the Swift Driver doesn't JSON-encode its own diagnostics, leading to things like swiftlang#5968. I filed swiftlang/swift-driver#1241 on the Swift Driver to get it to encode its JSON messages, but meanwhile, it turns out that we can fairly easily fix the fallback logic that SwiftPM uses when it emits raw output. It was simply missing a newline. It's safe to always add one, since the logic that parses JSON splits by newlines, so we won't find any terminating newlines. rdar://103608636 (cherry picked from commit 14d05cc)
|
Fixed in #5987 |
|
Also nominating for SwiftPM 5.8 as it's a safe fix. |
|
This fix adds the requisite newlines. I wonder if the original truncation had something to do with #5960. |
…ng newlines (#5987) (#5996) SwiftPM uses the Swift Driver's `-parseable-output` flag to get a sequence of length-prefixed JSON-encoded messages that it can read. Unfortunately the Swift Driver doesn't JSON-encode its own diagnostics, leading to things like #5968. I filed swiftlang/swift-driver#1241 on the Swift Driver to get it to encode its JSON messages, but meanwhile, it turns out that we can fairly easily fix the fallback logic that SwiftPM uses when it emits raw output. It was simply missing a newline. It's safe to always add one, since the logic that parses JSON splits by newlines, so we won't find any terminating newlines. rdar://103608636 (cherry picked from commit 14d05cc)
Description
Not sure this bug really belongs on SPM. I just built swift-format and the build ended with:
remark: Incremental compilation has been disabled: it is not compatible with whoremark: Incremental compilation has been disabled: it is not compatible with whoremark: Incremental compilation has been disabled: it is not compatible with whoremark: Incremental compilation has been disabled: it is not compatible with whoremark: Incremental compilation has been disabled: it is not compatible with whoremark: Incremental compilation has been disabled: it is not compatible with whoremark: Incremental compilation has been disabled: it is not compatible with who[11/16] Co[25/25] Compiling SwiftFormatTestSupport DiagnosingTestCase.swift
Build complete! (103.43s)
Something needs to be inserting a newline in the output before all remarks.
Expected behavior
No response
Actual behavior
No response
Steps to reproduce
Build swift-format from the CLI with swift 5.7
Swift Package Manager version/commit hash
No response
Swift & OS version (output of
swift --version && uname -a)No response
The text was updated successfully, but these errors were encountered: