Add new APIs libSwiftScan that can be used for cache query and cache
replay. This enables swift-driver or build system to query the cache and
replay the compilation results without invocation swift-frontend for
better scheduling.
This executable is intended to be installed in the toolchain and act as
an executable compiler plugin just like other 'macro' plugins.
This plugin server has an optional method 'loadPluginLibrary' that
dynamically loads dylib plugins.
The compiler has a newly added option '-external-plugin-path'. This
option receives a pair of the plugin library search path (just like
'-plugin-path') and the corresponding "plugin server" path, separated
by '#'. i.e.
-external-plugin-path
<plugin library search path>#<plugin server executable path>
For exmaple, when there's a macro decl:
@freestanding(expression)
macro stringify<T>(T) -> (T, String) =
#externalMacro(module: "BasicMacro", type: "StringifyMacro")
The compiler look for 'libBasicMacro.dylib' in '-plugin-path' paths,
if not found, it falls back to '-external-plugin-path' and tries to find
'libBasicMacro.dylib' in them. If it's found, the "plugin server" path
is launched just like an executable plugin, then 'loadPluginLibrary'
method is invoked via IPC, which 'dlopen' the library path in the plugin
server. At the actual macro expansion, the mangled name for
'BasicMacro.StringifyMacro' is used to resolve the macro just like
dylib plugins in the compiler.
This is useful for
* Isolating the plugin process, so the plugin crashes doesn't result
the compiler crash
* Being able to use library plugins linked with other `swift-syntax`
versions
rdar://105104850
This is the start of the removal of the C++ implementation of libSyntax
in favor of the new Swift Parser and Swift Syntax libraries. Now that
the Swift Parser has switched the SwiftSyntaxParser library over to
being a thin wrapper around the Swift Parser, there is no longer any
reason we need to retain any libSyntax infrastructure in the swift
compiler.
As a first step, delete the infrastructure that builds
lib_InternalSwiftSyntaxParser and convert any scripts that mention
it to instead mention the static mirror libraries. The --swiftsyntax
build-script flag has been retained and will now just execute the
SwiftSyntax and Swift Parser builds with the just-built tools.
This separates it from `libSwiftScan` and allows us to build this library without building much of the rest of the compiler.
Also refactor `utils/build-parser-lib` into `utils/build-tooling-libs` which builds both SwiftSyntaxParser and SwiftStaticMirror.
Made `BUILD_SOURCEKIT_XPC_SERVICE` into an option so it can be set externally.
It continues to default to `TRUE` if `HAVE_XPC_H AND SWIFT_BUILD_SOURCEKIT` is
true, and `FALSE` otherwise, but this allows a client to disable this ahead of
time and build a sourcekitd.framework without the XPC service.
This addresses <rdar://problem/85511711>.
Previously, we used SWIFT_INCLUDE_TESTS to control if we created build rules for
binaries just used to test as well as running the tests as well. In this commit,
I changed this behavior by adding an option called SWIFT_INCLUDE_TEST_BINARIES.
This will allow for the stage 1 swift build to build and install test binaries
into the just built toolchain for use by the stage 2 swift that builds the
stdlib.
* Make the `build-parser-lib` script more flexible on how it finds the llvm source path
* Make sure `swift-syntax-parser-test` can be built even though the script disables building for testing
* Fix a linker error for parser-only build
This library now relires on a static compiler library called `swiftDependencyScan`, which is also common to being used by `swift-frontend` for its dependency scanner invocations.
The tool is currently hard-coded to find functions in the SwiftUI library that take parameters of type `(...) -> T` where `T: View` but where the parameter isn't annotated with `@ViewBuilder`. The long-term vision here, of course, is that this reads and interprets a script file, but that's quite a bit more work (especially to generate a million bindings to the AST). In the meantime, I think having a functional harness that people familiar with the C++ API can easily hack on to make their own tools is still pretty useful.
The harness does try to open a script file and lex the first token of it, because that's exactly as far as I got before deciding to hard-code the query I wanted. Since this input is otherwise ignored, you can just point the tool at any old `.swift` file (or just an empty file) and it'll be fine.
Add a shared library with a C API that provides access to the syntactic parser with callbacks for the inference of raw syntax nodes.
This is primarily intended to be used by SwiftSyntax to speed-up source code parsing for it.
This seems to have been introduced for SwiftSyntax which is no longer in
the tree. No additional dependencies exist. Clean up the dead code
which prevents cross-compilation of just the host tools.
This is a separate tool so we can use all of LLVM without worrying about
creating a dependency from the demangler on LLVM's libsupport.
I am going to use it to fix cmpcodesize for the new mangling by eliminating
cmpcodesize's usage of regex to classify symbols. Instead, we can just read in
the yaml version of the symbol trees for each demangled node and process that
instead.
rdar://41146023
It is possible to disable the SourceKit build. However, we would
unconditionally add dependencies on targets which would only be
generated when SourceKit was being built, resulting in CMake failing to
configure. Restore the ability to disable the SourceKit build.
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.
