Motivated by need for protocol-based dynamic dispatch, which hasn't been possible in Embedded Swift due to a full ban on existentials. This lifts that restriction but only for class-bound existentials: Class-bound existentials are already (even in desktop Swift) much more lightweight than full existentials, as they don't need type metadata, their containers are typically 2 words only (reference + wtable pointer), don't incur copies (only retains+releases).
Included in this PR:
[x] Non-generic class-bound existentials, executable tests for those.
[x] Extension methods on protocols and using those from a class-bound existential.
[x] RuntimeEffects now differentiate between Existential and ExistentialClassBound.
[x] PerformanceDiagnostics don't flag ExistentialClassBound in Embedded Swift.
[x] WTables are generated in IRGen when needed.
Left for follow-up PRs:
[ ] Generic classes support
The generality of the `AvailabilityContext` name made it seem like it
encapsulates more than it does. Really it just augments `VersionRange` with
additional set algebra operations that are useful for availability
computations. The `AvailabilityContext` name should be reserved for something
pulls together more than just a single version.
This makes sure that Swift respects `-Xcc -stdlib=libc++` flags.
Clang already has existing logic to discover the system-wide libc++ installation on Linux. We rely on that logic here.
Importing a Swift module that was built with a different C++ stdlib is not supported and emits an error.
The Cxx module can be imported when compiling with any C++ stdlib. The synthesized conformances, e.g. to CxxRandomAccessCollection also work. However, CxxStdlib currently cannot be imported when compiling with libc++, since on Linux it refers to symbols from libstdc++ which have different mangled names in libc++.
rdar://118357548 / https://github.com/swiftlang/swift/issues/69825
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)
In embedded swift features are available independent of deployment and runtime targets because the runtime library is always statically linked to the program.
Fundamentally the problem here is that SILPassManager is creating an IRGenModule
without calling finalize() on it under some circumstances. It would be better to
fix that instead.
rdar://123923517
We add the `memory(argmem: readwrite)` attribute to swift_task_create,
which means that the call is only allowed to read or write "pointer
operands". LLVM is smart enough to look through obvious ptrtoint
casts, but not to look through integer selects and so on, which is what
we produce when there's an opaque optional operand that feeds into the
builtin. This was causing miscompiles under optimization when using
`@isolated(any)` function types for task creation, since we're not yet
clever enough to fold the function_extract_isolation for a known function
(and of course it's not necessarily a known function anyway).
To properly initialize the compiler instance on LLDB when debugging
embedded Swift programs, emit "-enable-embedded-swift" into the
DW_AT_APPLE_flags attribute of the compile unit.
Add a `-min-runtime-version` option that can be used to avoid problems
when building on Linux and Windows where because the runtime isn't
part of the OS, availability doesn't solve the problem of trying to
build the compiler against an older runtime.
Also add functions to IRGen to make it easy to test feature
availability using both the runtime version and the existing Darwin
availability support.
rdar://121522431
Currently only arrays can be put into a read-only data section.
"Regular" classes have dynamically initialized metadata, which needs to be stored into the isa field at runtime.
Static read-only arrays didn't work when passed to ObjectiveC as NSArray.
The storage class of static read-only arrays doesn't carry information about the Element type.
The new `__SwiftDeferredStaticNSArray` is generic over the element type and doesn't have to rely on the element type information of the array storage.
rdar://94185998
