This file was relying on Runtime/Config.h for SWIFT_CC() but
didn't include it directly.
I found this when some local experiments went awry in confusing
ways.
Foundation needs to be loaded early in the process for Swift's runtime
to properly initialize bridging support; otherwise it may cause issues
like unrecognized selectors. When scripting, load Foundation early in
performFrontend before any swift code runs.
rdar://129528115
It's not safe to unmap memory that has been registered with the
swift/objc runtimes. For now, avoid this by leaking the JIT object. In
the future we should be able to detach the JIT from the allocated
memory, or be more fine-grained about which memory needs to be preserved
and which can be freed.
rdar://128432487
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)
Add DYLD_FRAMEWORK_PATH=/System/Library/Frameworks to the environment when
constructing swift-frontend invocations for the interpreter so that dlopen can
find autolinked frameworks. This is intended to fix
https://github.com/apple/swift/issues/68785.
As a follow-up: don't expand runtime paths to find the path to the runtime in
libImmediate, but instead hard-code "/usr/lib/swift/libswiftCore.dylib" and
allow any overrides to be found via DYLD_LIBRARY_PATH (this ensures that dyld
treats whichever libswiftCore.dylib is found as override for the one in the
shared cache, which doesn't happen if dlopen is passed a non-standard path).
allocateCString includes the null end character, so we ended up with
two, in the symbol name. This made them not match, causing failures
while attempting to run the JIT'd program.
Remove one from the symbol name length to account for the null
character.
Refactor Immediate Mode to use the Materialization Unit API,
materializing the entire `SILModule` corresponding to the script
when the `main` symbol is looked up.
Some frameworks that previously had a separate swift overlay have been
merged in macOS 14. This is causing symbols to not resolve if using the
new SDK but running on an older OS in immediate mode. Ideally we would
handle this automatically in JITLink as is done by the system linker,
but in the meantime add a workaround to load the correct libraries
manually.
rdar://110371405
Using a virutal output backend to capture all the outputs from
swift-frontend invocation. This allows redirecting and/or mirroring
compiler outputs to multiple location using different OutputBackend.
As an example usage for the virtual outputs, teach swift compiler to
check its output determinism by running the compiler invocation
twice and compare the hash of all its outputs.
Virtual output will be used to enable caching in the future.
When looking for a Swift module on disk, we were scanning all module search paths if they contain the module we are searching for. In a setup where each module is contained in its own framework search path, this scaled quadratically with the number of modules being imported. E.g. a setup with 100 modules being imported form 100 module search paths could cause on the order of 10,000 checks of `FileSystem::exists`. While these checks are fairly fast (~10µs), they add up to ~100ms.
To improve this, perform a first scan of all module search paths and list the files they contain. From this, create a lookup map that maps filenames to the search paths they can be found in. E.g. for
```
searchPath1/
Module1.framework
searchPath2/
Module1.framework
Module2.swiftmodule
```
we create the following lookup table
```
Module1.framework -> [searchPath1, searchPath2]
Module2.swiftmodule -> [searchPath2]
```
This is for the 'freestanding' build to stop assuming the platform has argc/argv.
- Introduce a new sub-library, libswiftCommandLineSupport.a
- Move stubs/CommandLine.cpp into this library
- Conditionally embed it into libswiftCore
- Conditionally embed it into libswiftPrivateLibcExtras if not in libswiftCore to support testing
- Add SWIFT_STDLIB_HAS_COMMANDLINE CMake (and build-script) flag
* add the (still empty) libswift package
* add build support for libswift in CMake
* add libswift to swift-frontend and sil-opt
The build can be controlled with the LIBSWIFT_BUILD_MODE cmake variable: by default it’s “DISABLE”, which means that libswift is not built. If it’s “HOSTTOOLS”, libswift is built with a pre-installed toolchain on the host system.
Add a debugging mechanism that enables the JIT to dump the LLVM IR and
object files to enable debugging the JIT. This makes it easier to debug
the JIT mode failures. The idea was from Lang Hames!
With an inverted pipeline, IRGen needs to be able
to compute the linker directives itself, so sink
it down such that it can be computed by the
`IRGenDescriptor`.
With an inverted pipeline, IRGen needs to be able
to compute the linker directives itself, so sink
it down such that it can be computed by the
`IRGenDescriptor`.
Delete all of the formalism and infrastructure around maintaining our own copy of the global context. The final frontier is the Builtins, which need to lookup intrinsics in a given scratch context and convert them into the appropriate Swift annotations and types. As these utilities have wormed their way through the compiler, I have decided to leave this alone for now.
All of this is in service of working around a pile of deficiencies in LLVM's Module Linker, and LLVMContext abstractions. And because we're just gonna scrap this code soon anyways, it's probably not worth the effort to push on these bugs to block the broader cleanup here.
The LLVM Linker currently does not support linking modules allocated in different contexts. This appears to be motivated in part by LLVM's lack of a facility to clone a module from one context to another. This, in turn, appears to be motivated in part by LLVMContext's lack of a robust notion of identity - which makes it harder than it needs to be to detect the mismatch.
However, it is not impossible to clone a module across contexts. We need to get creative and round-trip the module through some serialization layer. Out of convenience, that layer is currently textual IR, though bitcode would work equally well.
Given that it is no longer under the caller's control which LLVMContext we generate code in, put all the above together to arrive at an egregious hack that clones the module into the LLVMContext the REPL expects.
