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)
Previously, if a request R evaluated itself N times, we would emit N
"circular reference" diagnostics. These add no value, so instead let's
cache the user-provided default value on the first circular evaluation.
This changes things slightly so that instead of returning an
llvm::Expected<Request::OutputType>, various evaluator methods take
a callback which can produce the default value.
The existing evaluateOrDefault() interface is unchanged, and a new
evaluateOrFatal() entry point replaces
llvm::cantFail(ctx.evaluator(...)).
Direct callers of the evaluator's operator() were updated to pass in
the callback. The benefit of the callback over evaluateOrDefault() is
that if the default value is expensive to constuct, like a dummy
generic signature, we will only construct it in the case where a
cycle actually happened, otherwise we just delete the callback.
(cherry picked from commit b8fcf1c709efa6cd28e1217bd0efe876f7c0d2b7)
Decls with a package access level are currently set to public SIL
linkages. This limits the ability to have more fine-grained control
and optimize around resilience and serialization.
This PR introduces a separate SIL linkage and FormalLinkage for
package decls, pipes them down to IRGen, and updates linkage checks
at call sites to include package linkage.
Resolves rdar://121409846
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
