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.
