This wires up the new macro properly into the build machinery to ensure
that the `distribution` target properly builds and installs the
dependencies. This fixes the missing `swift-plugin-server` on Windows.
Account for import libraries and the associated layout difference on
platforms (e.g. DLLs are placed in `bin`). This is required to enable
building the macro path on Windows.
Wrap the `InheritedEntry` array available on both `ExtensionDecl` and
`TypeDecl` in a new `InheritedTypes` class. This class will provide shared
conveniences for working with inherited type clauses. NFC.
This begins reworking the API to be less POSIX centric and more
generally usable. The API was defined in terms of `dlopen`/`dlsym`
rather than the better suited `llvm::sys::DynamicLibrary` APIs which
would avoid most of the work that needs to be done here for platform
specifics.
swift-compatibility-symbols, swift-def-to-strings-converter,
and swift-serialize-diagnostics don't use any Swift modules. But when
SWIFT_SWIFT_PARSER was enabled, they are linked with swiftCore. But
these binaries can be executed before the runtime is being built.
We need to stop them linking with swiftCore.
libSwiftScan is built in 'lib' but installed in 'lib/swift/host' RUNPATH
should have correct '$ORIGIN/../{platform}' to load 'swiftCore' runtime
library.
In Linux. Instead of setting temporary "fallback" RUNPATH, Set
LD_LIBRARY_PATH to builder's runtime when building standard library.
So we don't need to strip the temporary RUNPATH when installing.
interface for index.
An explicit module build compile is unable to do so because it does not have
access to the interfaces. Doing this in the first place is a workaround for a
known bug, which will require to be solved at the root cause instead (e.g.
Deserialization Safety feature).
Resolves rdar://113165898
and Swift parser integration is enabled.
If swift parser integration is enabled, SwiftSyntax libraries are always
built with host tools. Other SwiftCompilerSources modules must use the
same runtime with parser libraries.
For compiling codes required for macro support, we now need swiftc
compiler in the build machine.
Unlike Darwin OSes, where swiftCore runtime is guaranteed to be present
in /usr/lib, Linux doesn't have ABI stability and the stdlib of the
build machine is not at the specific location. So the built compiler
cannot relies on the shared object in the toolchain.
LLVM install_symlink takes a new argument on whether to create a symlink
or copy binaries when run. -- https://reviews.llvm.org/D145443
The variable that controls this in LLVM is `LLVM_USE_SYMLINKS`, which
defaults to `ON` on Unix-y hosts, but otherwise is false so that Windows
works. This is a configurable option, so Windows configs that can
support symlinks can take advantage of symlinks and save some space.
`LLVM_USE_SYMLINKS` is not exported from LLVM though, so we can't see
it to use. Instead, we have `SWIFT_USE_SYMLINKS`.
Pointer `llvm/Support/Host.h` at `llvm/TargetParser/Host.h`.
Replacing deprecated API `startswith_insensitive` with replacement
`starts_with_insensitive`.
If we encounter bad data in the target, we could end up trying to print an infinite list of jobs. Clamp it to 1,000 so we fail more gracefully.
rdar://113417637
