Include directories are already specified in parent directories or
dependencies, and `-I` for swiftc are propagated to ClangImporter. We
don't need to specify them manually.
Wherever there is a syntax collection in the syntax tree that can involve
an `#if` clause, evaluate the `#if` conditions to find the active clause,
then recurse into the active clause (if one exists) to "flatten" the
translated collection to only contain active elements.
Note that this does not yet handle #if for postfix expressions.
This concrete implementation of the BuildConfiguration allows the use of
the SwiftIfConfig library's APIs where the build configuration comes from
the compiler itself.
Separate swift-syntax libs for the compiler and for the library plugins.
Compiler communicates with library plugins using serialized messages
just like executable plugins.
* `lib/swift/host/compiler/lib_Compiler*.dylib`(`lib/CompilerSwiftSyntax`):
swift-syntax libraries for compiler. Library evolution is disabled.
* Compiler (`ASTGen` and `swiftIDEUtilsBridging`) only depends on
`lib/swift/host/compiler` libraries.
* `SwiftInProcPluginServer`: In-process plugin server shared library.
This has one `swift_inproc_plugins_handle_message` entry point that
receives a message and return the response.
* In the compiler
* Add `-in-process-plugin-server-path` front-end option, which specifies
the `SwiftInProcPluginServer` shared library path.
* Remove `LoadedLibraryPlugin`, because all library plugins are managed
by `SwiftInProcPluginServer`
* Introduce abstract `CompilerPlugin` class that has 2 subclasses:
* `LoadedExecutablePlugin` existing class that represents an
executable plugin
* `InProcessPlugins` wraps `dlopen`ed `SwiftInProcPluginServer`
* Unified the code path in `TypeCheckMacros.cpp` and `ASTGen`, the
difference between executable plugins and library plugins are now
abstracted by `CompilerPlugin`
When built as part of the compiler toolchain SwiftSyntax is built with library
evolution enabled. This means that switches over enums from SwiftSyntax must
include a default case to be considered exhaustive, or a warning will be
emitted. This change suppresses those warnings by adding `@unknown default`
cases wherever they are expected. As a compromise, these `@unknown default`
cases are wrapped with a `#if` to ensure they are only included in the CMake
build of ASTGen, but continue to be omitted from the SPM build which compiler
engineers use to iterate on ASTGen's implementation. This is needed to avoid
generating the opposite warning during the SPM build, since the compiler thinks
the `@unknown default` case is superfluous when SwiftSyntax is built
non-resiliently. As an aside, this catch-22 is a bummer and I think we should
change the compiler to suppress the unreachable default warning when the
default is annotated `@unknown`.
Use similar scheme as DeclAttribute.
* Create `BridgedTypeAttribute.createSimple()` and
`BridgedTypeAttributes.add()`, instead of
`BridgedTypeAttributes.addSimple()`
* Create `DeclAttributes::createSimple()` to align with `TypeAttribute`
`llvm::None` is deprecated, but still being used in Swift until we have
fewer 5.10 cherry-picks. Add the `SWIFT_TARGET` definition to ignore the
deprecation.
ASTGen always builds with the host Swift compiler, without requiring
bootstrapping, and is enabled in more places. Move the regex literal
parsing logic there so it is enabled in more host environments, and
makes use of CMake's Swift support. Enable all of the regex literal
tests when ASTGen is built, to ensure everything is working.
Remove the "AST" and "Parse" Swift modules from SwiftCompilerSources,
because they are no longer needed.
* 'ASTGenVisitor' has a reference to a legacy C++ Parser configured for
ASTGen.
* If 'ASTGenVisitor' encounters a AST node that hasn't been migrated,
call parse(Decl|Stmt|Expr|Type) to parse the position using the legacy
parser.
* The legacy parser calls ASTGen's
'swift_ASTGen_build(Decl|Stmt|Expr|Type)' for each ASTNode "parsing"
(unless the call is not directly from the ASTGen.)
rdar://117151886
Use FetchContent to include swift-syntax directly in swift. This can be
thought of as an `add_subdirectory` for a directory outside the root.
The default build directory will be `_deps/swiftsyntax-subbuild/`, though
the modules and shared libraries will be built in `lib/swift/host` by
passing down `SWIFT_HOST_LIBRARIES_DEST_DIR` to avoid copying them as we
were doing previously.
Rather than requiring macro implementations to add required whitespace
and indentation, basic format all macro expansions. Right now this uses
the default four space indentation, we can consider having that inferred
later. Macros can opt-out of automatic formatting by implementing
`formatMode` and setting it to `.disabled`.
Also moves the extra newlines before/after expansions to a new "Inline
Macro" refactoring.
Resolves rdar://107731047.
* Move `add_pure_swift_host_library()` from lib/CMakeLists.txt to
AddPureSwift.cmake so that code outside `lib` can use it
* Add `add_pure_swift_host_tool()` function to make a pure Swift
host executable target (for future usages)
* Specify depending `SwiftSyntax` modules explicitly because not all
Swift libraries uses all SwiftSyntax libraries
For future usage from other host libraries written in Swift
For CMake:
* Explicitly specify LINKER_LANGAGE to CXX in existing components so
that 'swiftc' is not used when linking with 'swiftASTGen'
* Add 'EMIT_MODULE' argument to 'add_pure_swift_host_library' to emit
.swiftmodule usable from other Swift libraries.
Refactor the build support for ASTGen and ObservationMacros. Both have
nearly-identical copies of a bunch of messy, workaround-laden CMake
code to build "pure" Swift host libraries using CMake's Swift support.
Instead, introduce `add_pure_swift_host_library` to centralize all of
the hacks to build a host library that's all Swift, using CMake's
support directly (rather than custom commands), and link against the
swift-syntax stack. Switch ASTGen directly over to this.
Add `add_swift_macro_library` on top of this, to make it easy to
create a macro library and install it into the appopriate plugin
directory. Switch ObservationMacros over to this.
Consider the case of A -> B. The previous workaround will add a
forced-B-dep.swift to A that is touched if B rebuilds. So if B is
rebuilt, A is also rebuilt. But A itself has no real changes, and so
none of its object files are built and none of the mtimes are updated.
Thus, A is then rebuilt again on the next run because its input
(forced-B-dep.swift) is newer than the corresponding object file. To
prevent this, update the mtime for the library and object files after the
build (which is actually a link step that both compiles and links).
Executable compiler plugins are programs invoked by the host compiler
and communicate with the host with IPC via standard IO (stdin/stdout.)
Each message is serialized in JSON, prefixed with a header which is a
64bit little-endian integer indicating the size of the message.
* Basic/ExecuteWithPipe: External program invocation. Lik
llvm::sys::ExecuteNoWait() but establishing pipes to the child's
stdin/stdout
* Basic/Sandbox: Sandboxed execution helper. Create command line
arguments to be executed in sandbox environment (similar to SwiftPM's
pluging sandbox)
* AST/PluginRepository: ASTContext independent plugin manager
* ASTGen/PluginHost: Communication with the plugin. Messages are
serialized by ASTGen/LLVMJSON
rdar://101508815
The runtime compat 5.6 library is not available in current toolchains.
The stage-0 compiler builds fine since the builder compiler is not aware
of the 5.6 library, but the stage-1 compiler will not link since the
builder libraries don't have the compat 5.6 library, while the stage-0
compiler is aware of the library and attempts to link it into the built
products. The issue is that the bootstrap goes and uses the libraries
off of the builder instead of the things that actually match the
compiler.
This is currently safe because the 5.6 compat library only contains
concurrency runtime fixes and the compiler frontend does not use
concurrency yet. If this changes, we will need to re-enable this and
make the bootstrap use the libraries correctly.
Rather than trying to patch up the "basic" macro expansion context
that comes from the swift-syntax package, implement our own based
on the new SourceManager. Fixes the `location(of:)` operation.
Add SourceManager that can keep track of multiple source file syntax
nodes along with their external representations. The source manager can
emit diagnostics into any of those files, including tracking any
explicitly "detached" syntax nodes used for macro expansion.
Make sure we detach syntax nodes before passing them to macro
implementations, so they cannot see more of the source file than they
are permitted. We hadn't been doing this before (by accident), and
doing so motivated the introduction of the SourceManager.
Additionally, perform operator folding on macro arguments as part of
detaching them. Macro clients shouldn't have to do this, and moreover,
when clients do this, they lose the ability to easily emit diagnostics
on the now-folded nodes.
Replace the use of the "consistency check" vended by swift-syntax with
an ASTGen-implemented operation that emits diagnostics from the new parser
via the normal diagnostic engine. This eliminates our last dependency
on SwiftCompilerSupport, so stop linking it.
Implement an ASTGen operation to bridge swift-syntax diagnostics, as
produced by the parser, operator folding, and macros, over to the C++
diagnostic engine infrastructure. Use this to wire up macro expansion
diagnostics.
Make the build directory for lib/swift/host look like the eventually
toolchain directory by copying in all of the Swift module files. This
makes it easier to correctly build anything requiring these libraries
against either the build or the install directories.
