SwiftSyntax: Teach SwiftSyntax to use SourceKit to serialize syntax trees. #14424
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
When using SwiftSyntax as a standalone tool, we invoke Swiftc internally to get the serialized syntax tree. This is not ideal for several reasons: (1) we have to hard-code the relative path of swiftc to invoke it; (2) we have to rely on standard input/output to pass the tree across the process boundaries; and (3) we have to maintain two different ways to get syntax tree (swiftc and sourcekitd). This patch attempts to teach SwiftSyntax to use SourceKit to get the tree just like other clients. We first add a SourceKit client library written in Swift; and next teach SwiftSyntax to use this SourceKit client-side library. For platforms other than MacOS, we still use Swiftc to get syntax trees. This patch also re-enables several flaky tests.
|
@swift-ci please smoke test |
| return Dictionary(dict: val) | ||
| } | ||
|
|
||
| public func asAnyObject() -> AnyObject? { |
There was a problem hiding this comment.
What's the reason you're using AnyObject and Foundation types here instead of stdlib types?
There was a problem hiding this comment.
oh, I'm not sure because this is borrowed code from internal clients. I'll try to convert to stdlib types.
|
Super glad to see SwiftSyntax communicating with SourceKit! |
|
@harlanhaskins it seems we don't need the bridging with NS-types so I removed them altogether. |
|
@swift-ci please smoke test |
|
@swift-ci please smoke test |
|
@swift-ci please smoke test |
nkcsgexi
changed the title
|
@nkcsgexi Could this change have something to do with this source compatibility failure? |
DougGregor
added a commit
to DougGregor/swift
that referenced
this pull request
Feb 9, 2018
… serialize syntax trees. (swiftlang#14424)" (swiftlang#14465)" This reverts commit f8c77e1.
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.
When using SwiftSyntax as a standalone tool, we invoke Swiftc
internally to get the serialized syntax tree. This is not ideal for
several reasons: (1) we have to hard-code the relative path of swiftc
to invoke it; (2) we have to rely on standard input/output to pass the
tree across the process boundaries; and (3) we have to maintain two
different ways to get syntax tree (swiftc and sourcekitd).
This patch attempts to teach SwiftSyntax to use SourceKit to get the
tree just like other clients. We first add a SourceKit client library
written in Swift; and next teach SwiftSyntax to use this SourceKit
client-side library. For platforms other than MacOS, we still use Swiftc
to get syntax trees.
This patch also re-enables several flaky tests.