* [SwiftSyntax] Add SyntaxRewriter.visitAny(_:)
This function, when overridden, allows Syntax rewriters to perform custom dynamic visitation behavior. If a user wanted to, say, store a series of transformations accessible by metatype, they can override visitAny and do their own runtime dispatch.
If a non-nil result is returned from visitAny, the original specialized visitors are skipped.
* [SwiftSyntax] Add replace method SyntaxCollections
* Change replaceSubrange method call to subscript setter call
* [SwiftSyntax] Add test for SyntaxCollections
* Fix mistakes in SyntaxCollections tests
* Use syntax's raw value instead of syntax itself in replacing method
* Update SyntaxCollections tests
Although libSyntax is designed in a way that trivia is attached to
tokens, we shouldn't restrict clients to access trivia only from a token.
An example can be doc-comment, which conceptually attaches to a declaration rather
than the start token of a declaration, like at-attributes.
Syntax nodes are designed as reusable blocks to construct Swift source
code. For this reason, we don't track absolute position in each node;
instead, the absolute position should be calculated on the fly when
needed. We recently found absolute positions are useful to bridge with
sourcekitd, which typically speaks in the language of line, column and
offset. Therefore, this patch tries to add a computed
property on SyntaxNode to get its absolute position.
To compute the absolute position of a SyntaxNode from scratch requires tree traversal.
However, getting the absolute position from these added APIs doesn't necessarily
mean we'll traverse since SyntaxData will actively cache the computed position.
Also, since we recursively compute the absolute position, all the position caches
for a SyntaxNode's previous siblings and ancestors will be populated as well during
the calculation of this SyntaxNode.
The sourcekitd client library provides parsing APIs for SwiftSyntax users.
The internal use of sourcekit service is an implementation detail that end users
shouldn't worry about.
When using SwiftSyntax as a standalone tool, we invoke Swiftc
internally to get serialized syntax trees. 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 SourceKitd to get the
tree just like other clients. We first add a SourceKitd client library
written in Swift; and next teach SwiftSyntax to adopt this SourceKitd
client-side library. For platforms other than MacOS, we still use Swiftc
to get syntax trees. This client library also allows us to add
SourceKitd tests in Swift.
This patch also re-enables several flaky tests.
Based on the feedbacks from our early adopters, separating syntax tree analysis
with transformation is a common pattern. Thus, we introduce a read-only
syntax tree visitor to help the analysis phase. This visitor never alters the
content of a tree being visited, in contrast to SyntaxRewriter which always does.
This patch provides an API and Serialization for clang-style diagnostics
from within Swift. Libraries can use this API to pop their own custom
diagnostics that can be serialized to JSON.
* [SwiftSyntax] Fix SyntaxChildren iteration
SyntaxChildren.Iterator stops the first time it sees a nil child;
since it traverses all indexes without considering presence, this
causes it to terminate iteration early if there is a missing child
in the list.
* [SwiftSyntax] Add tests for SyntaxChildren
* [CMake] Only build SwiftSyntax if building SDK overlays
SwiftSyntax depends on Foundation, which depends on the SDK overlays
being built. However, the existing build configuration tried to build
SwiftSyntax even if the SDK overlays were not built. Ensure we're
building overlays before building SwiftSyntax, and guard tests with an
sdk_overlay test.
* Remove TODO comment
This is, unfortunately, the quickest workaround to get SwiftSyntax
building properly and generating a proper module. I'm going to take some
time to figure out what global mutable state exactly is touched inside
stdlib/ that suddenly makes this work, but for now, get the tests re-enabled.
* Create Swift libSyntax API
This patch is an initial implementation of the Swift libSyntax API. It
aims to provide all features of the C++ API but exposed to Swift.
It currently resides in SwiftExperimental and will likely exist in a
molten state for a while.
* Only build SwiftSyntax on macOS
