[5.7-04182022][Parseable Output] Compute file extensions using full extension strings & emit output in WMO #58871
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…shed messages on a per-primary basis. Which means that `-frontend-parseable-output` had no effect in contexts where no primary inputs are specified, such as WMO. This change fixes that by also emitting began/finished messages when no primary outputs are specified. Resolves rdar://91999048
artemcm
changed the title
|
@swift-ci please test |
Generation of valid JSON output for parseable output depends on being able to determine file types of inputs and outputs of compilation tasks. FileTypes.def defines multiple file kinds with multiple '.' extensions, such as '.abi.json' or '.features.json', but existing code attempted to compute file outputs only using the trailing suffix of the path after the last '.'. This led to some files not being recognized, which led to us not being able to generate valid JSON. Resolves rdar://92961252
artemcm
force-pushed
the
57-04182022ParseableFixes
branch
from
02f1123 to
1186973
Compare
|
@swift-ci please test |
airspeedswift
approved these changes
May 13, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Cherry-pick of #58422
Cherry-pick of #58865
• Explanation: Generation of valid JSON output for compiler frontend's parseable output depends on being able to determine file types of inputs and outputs of compilation tasks. The compiler defines multiple file kinds with multiple . extensions, such as .abi.json or .private.swiftinterface, but existing code attempts to compute file outputs only using the trailing suffix of the path after the last .. This led to some file kinds not being recognized, which led to us not being able to generate valid JSON.
• Scope of Issue: Compilation tasks launched by build systems that consume parseable-output that specify certain output kinds (for example an ABI descriptor) and fail, do not result in visible error diagnostics being emitted.
• Origination: This particular case was not handled in the implementation of frontend-emitted parseable-output which only started being used recently. The problem of determining file kinds using only the trailing . suffix is more-general in the compiler and needs to be addressed separately. This fix is narrow and specific to generation of parseable-output JSON.
• Risk: Low
• Automated Testing: Automated test added to the compiler test suite
5.7 Cherry-pick PR: #58868
Resolves rdar://92961252
• Explanation: Frontend-emitted parseable-output did not previously emit messages for whole-module jobs because its original intent was to emit messages describing batch compilation jobs. We recently started using frontend-emitted parseable-output and require that it also emit messages for WMO compiler tasks for consistency. This change adds emission of JSON parseable-output messages for WMO compiler jobs. It is already merged for
release/5.7, but the above fix is built on top of the fix here so it is worth bringing them both together.• Scope of Issue: Failing WMO compilation tasks launched by build systems consuming frontend-emitted parseable-output did not previously emit error messages.
• Origination: This particular case was not handled in the implementation of frontend-emitted parseable-output which only started being used recently.
• Risk: Low
This was previously cherry-picked into 5.7 in #58471
Resolves rdar://91999048