Previously, the compiler waited the plugin process with
`llvm::sys::Wait(pid, /*SecondsToWait=*/1)`. But in the `Wait`
implementation, it sets the `alarm(SecondsToWait)`, then
`wait4(pid, ..)` so if the alarm fires before the `wait4` call,
it may miss the timeout and can wait indefinitely. To mitigate that
risk,use `10` for the timeout value.
rdar://150474701
`llvm::sys::Wait(process, /*SecondsToWait=*/0)` perform a non-blocking
`wait`. That means the plugin goes a zombie if it hasn't exited.
Set `SecondsToWait` 1 so it wait for 1 second and kill it on the time
out. Usually, when the pipe is closed, the plugins detect the EOF in
stdin and exits immediately, fo the parent process usually don't wait
for the timeout.
rdar://148110944
llvm::DynamicLibrary does dlclose on all the libraries when global
destructor runs. Which causes dangling pointers if the library contains
Swift code.
rdar://131048379
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`
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
LLVM is gearing up to move to `std::endianness` and as part of that has
moved `llvm::support::endianness` to `llvm::endianness`
(bbdbcd83e6702f314d147a680247058a899ba261). Rename our uses.
`-disable-sandbox` to disable sandboxing when invoking subprocess from
from the frontend. Since `sandbox(7)` in macOS doesn't support nested
sandbox, complation used to fail when the parent build process is sandboxed.
Implement process launching on Windows to support macros. Prefer to use
the LLVM types wherever possible. The pipes are converted into file
descriptors as the types are internal to the process. This allows us to
have similar paths on both sides and avoid having to drag in `Windows.h`
for the definition of `HANDLE`. This is the core missing functionality
for Windows to support macros.
Previously, the compiler fails to read the result from 'getCapability'
IPC message, it used to just emit a fatalError and crashed.
Instead, propagate the error status and diagnose it.
rdar://108022847
`LoadedLibraryPlugin` is currently just a wrapper of `void` pointer from
`dlopen`. This will be convenient for abstracting platform specific
dynamic linrary handling.
Make a single 'PluginRegistry' and share it between SwiftASTManager,
IDEInspectionInstance, and CompileInstance. And inject the plugin
registry to ASTContext right after 'CompilerInstance.setup()'
That way, all sema-capable ASTContext in SourceKit share a single
PluginRegistry.
When loading plugins from `-plugin-path`, use the global `PluginRegistry` to keep a record of what's loaded. Emit these dependencies to the loaded module trace.
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
