* [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.
We have two similar objects for source location. AbsoluteLocation
calculates the offset of a syntax node on the fly. SourceLocation is
designed to serialize a Swift syntax diagnostics to the driver. The only
difference is AbsoluteLocation doesn't contain source file name however
SourceLocation does. This patch bridges them by making AbsoluteLocation
a private member of SourceLocation. We also expect Swift syntax to
be file-name agnostic. The clients should keep track of the file name
when emitting diagnostics.
* [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.
Swift syntax APIs lack an abstract way of accessing children. The client has to
down-cast a syntax node to the leaf type to access any of its children. However,
some children are common among different syntax kinds, e.g.
DeclAttributeSyntax and DeclMembers. We should allow an abstract way to
access and modify them, so that clients can avoid logic duplication.
This patch adds a mechanism to define new traits and specify satisfied
traits in specific syntax nodes. A trait is a set of common children
and implemented in Swift as a protocol for syntax nodes to conform to.
As a proof-of-concept, we added two traits for now including DeclGroupSyntax
and BracedSyntax.
Resolves: SR-6931 and SR-6916
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.
* Make Range conditionally a Collection
* Convert ClosedRange to conditionally a collection
* De-gyb Range/ClosedRange, refactoring some methods.
* Remove use of Countable{Closed}Range from stdlib
* Remove Countable use from Foundation
* Fix test errors and warnings resulting from Range/CountableRange collapse
* fix prespecialize test for new mangling
* Update CoreAudio use of CountableRange
* Update SwiftSyntax use of CountableRange
* Restore ClosedRange.Index: Hashable conformance
* Move fixed typechecker slowness test for array-of-ranges from slow to fast, yay
* Apply Doug's patch to loosen test to just check for error
Since our recent integration with SourceKit, clients may get a SourceFileSyntax
in a serialized form from SourceKit response. We need an API in the
SwiftSyntax framework to decode this form. This'll be a more common
pattern to get a Swift side syntax tree than invoking swiftc internally.
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.
This patch also performs minor refactoring to align syntax parsing
context with the right scope. We start to support the generic clauses
because they are necessary pieces to construct struct or
function syntax node.
The default IndexingIterator for a custom collection is not suitable for
subclasses that specialize the element type the way libSyntax does.
Overriding it with a more specific iterator, even with something like
covariant overrides, would not work because it the iterator is generic
over its base collection, not its element type.
Provide a custom iterator parameterized by the element type instead.
