When using newer builds of clang with xcodebuild, the following output is spewed to STDERR for every single clang invocation: 2014-04-01 09:56:33.518 xcodebuild[32115:db03] DVTAssertions: Warning in /SourceCache/IDEXcode3ProjectSupport/IDEXcode3ProjectSupport-6080.2/Xcode3Core/LegacyProjects/Frameworks/DevToolsCore/DevToolsCore/BuildSystem/BuildCommandResultsPostprocessing/XCClangResultsPostprocessor.m:88 Details: Unable to read diagnostics from file "/Volumes/Data/Build/WebCore.build/Release/WebCore.build/Objects-normal/x86_64/AffineTransform.dia" (Invalid File): diagnostics file is a newer version than the one supported Object: <XCClangResultsPostprocessor: 0x7ff56303fdb0> Method: -generateDiagnosticsFromFile:logSectionRecorder: Thread: <NSThread: 0x7ff562e125e0>{name = (null), num = 21} Please file a bug at http://bugreport.apple.com with this warning message and any useful information you can provide. The filter-build-webkit script should know how to ignore this useless output when combining STDOUT and STDERR for the build command.
Created attachment 228296 [details] Patch v1
Created attachment 228297 [details] Patch v2 Update copyright.
Created attachment 228298 [details] Patch v3 Fix typo in ChangeLog.
Comment on attachment 228298 [details] Patch v3 Although I would love to ignore them, shouldn't we consider filing bugs if the compiler / tools asks us to?
(In reply to comment #4) > (From update of attachment 228298 [details]) > Although I would love to ignore them, shouldn't we consider filing bugs if the compiler / tools asks us to? No, because it's an unsupported configuration that will be fixed when they integrate a newer version of clang at a later date.
Comment on attachment 228298 [details] Patch v3 View in context: https://bugs.webkit.org/attachment.cgi?id=228298&action=review > Tools/ChangeLog:10 > + (shouldIgnoreLine): Ignore DVTAssertions related to new builds > + of clang. This description may not fully represent the impact of the proposed change. That is, we may also ignore the error details of any Xcode warning. See my remark below for more details. > Tools/Scripts/filter-build-webkit:261 > + return 1 if $line =~ /^(Details|Object|Method|Function|Thread):/; > + return 1 if $line =~ /^Please file a bug at /; Are these lines only emitted for DVTAssertions? If not, then we'll be omitting these lines from all Xcode errors. (Is that OK?) We may want to consider omitting these lines for only DVTAssertions.
You could always just tee the full build log to a file and then pipe to the filter. I wonder if we do something similar to that on the bots.
(In reply to comment #7) > You could always just tee the full build log to a file and then pipe to the filter. I wonder if we do something similar to that on the bots. I do this all the time when building so I can go back to reference anything I miss: $ make debug ARCHS="x86_64" 2>&1 | tee build-debug.txt | ./Tools/Scripts/filter-build-webkit
(In reply to comment #6) > (From update of attachment 228298 [details]) > View in context: https://bugs.webkit.org/attachment.cgi?id=228298&action=review > > > Tools/ChangeLog:10 > > + (shouldIgnoreLine): Ignore DVTAssertions related to new builds > > + of clang. > > This description may not fully represent the impact of the proposed change. That is, we may also ignore the error details of any Xcode warning. See my remark below for more details. You are correct, I could say this instead: Ignore DVTAssertions related to new builds of clang, plus debug data for all DVTAssertions. > > Tools/Scripts/filter-build-webkit:261 > > + return 1 if $line =~ /^(Details|Object|Method|Function|Thread):/; > > + return 1 if $line =~ /^Please file a bug at /; > > Are these lines only emitted for DVTAssertions? If not, then we'll be omitting these lines from all Xcode errors. (Is that OK?) We may want to consider omitting these lines for only DVTAssertions. I can't say for sure that these lines are output only for DVTAssertions, but based on my experience, they are output with every DVTAssertion, and they add nothing of immediate value if you're going to filter the output anyway. As noted in Comment #8, I always tee the full build output to a file, and the filter the rest via the script. If you're filtering output, you want the minimum necessary to spot an issue, and based on what we know so far, ignoring the Details|Object|Method|Function|Thread messages won't skip anything important.
Committed r166674: <http://trac.webkit.org/changeset/166674>