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.
* [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
* Unify the capitalization across all user-visible error messages (fatal errors, assertion failures, precondition failures) produced by the runtime, standard library and the compiler.
* Update some more tests to the new expectations.
* 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
