When Embedded Swift emits a symbol that was imported from another
module, ensure that the symbol is emitted as a weak definition. This
way, importing the same module (and using its symbol) into several
different modules doesn't cause duplicate-symbol errors at link time.
Rather, the linker will merge the different symbol definitions. This
makes Embedded Swift libraries work without resorting to
`-mergeable-symbols` or `-emit-empty-object-file`.
If `LinkEntity::isTypeKind()` is true, `IRGenModule::getAddrOfLLVMVariable` assumes that we can safely call
`LinkEntity::getType()`, which does `reinterpret_cast` of `LinkEntity::Pointer` to `TypeBase *`. However, for SIL
differentiability witness, the pointer has `SILDifferentiabilityWitness *` type, which is not derived from `TypeBase`. So, such a cast is not allowed.
Just as with `ProtocolWitnessTableLazyAccessFunction` and `ProtocolWitnessTableLazyCacheVariable` link entity kinds (which are also type kinds), we should use `SecondaryPointer` instead of `Pointer` for storing payload here, while setting `Pointer` to `nullptr`.
Key paths can't reference non-escapable or non-copyable storage declarations,
so we don't need to refer to them resiliently, and can elide their property
descriptors.
However, declarations may still be conditionally Copyable and Escapable, and
if so, then they still need a property descriptor for resilient key path
references. When a property or subscript can be used in a context where it
is fully Copyable and Escapable, emit the property descriptor in a generic
environment constrained by the necessary conditional constraints.
Fixes rdar://151628396.
There are numerous entity kinds declared after
`ProtocolWitnessTableLazyAccessFunction` which aren't type kinds. Group
all those which are type kinds together for now. In the fullness of
time it would probably we wise to replace this implementation with a
switch statement so that when new kinds are added there is a chance that
the type-ness of that kind can be considered.
The well known builtin and structural types are strongly defined in the
runtime which is compacted into the standard library. Given that the VWT
is defined in the runtime, it is not visible to the Swift compilation
process and as we do not provide a Swift definition, we would previously
compute the linkage as being module external (`dllimport` for shared
library builds). This formed incorrect references to these variables and
would require thunking to adjust the references.
One special case that we add here is the "any function" type
representation (`@escaping () -> ()`) as we do use the VWT for this type
in the standard library but do not consider it part of the well known
builtin or structural type enumeration.
These errors were previously being swallowed by the build system and
thus escaped from being fixed when the other cases of incorrect DLL
storage were.
Property descriptors for static properties were only recently introduced with
SE-438. Since these symbols are not present in Swift libraries that were
compiled with earlier versions of the compiler, it is not safe for
`#_hasSymbol` to check for the property descriptor symbols, since they can be
absent at either link time or runtime.
Resolves rdar://139749275.
The main change here is to associate a witness table with a `ProtocolConformance` instead of a `RootProtocolConformance`.
A `ProtocolConformance` is the base class and can be a `RootProtocolConformance` or a `SpecializedProtocolConformance`.
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.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
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
- VTableSpecializer, a new pass that synthesizes a new vtable per each observed concrete type used
- Don't use full type metadata refs in embedded Swift
- Lazily emit specialized class metadata (LazySpecializedClassMetadata) in IRGen
- Don't emit regular class metadata for a class decl if it's generic (only emit the specialized metadata)
- In embedded Swift, classes get a simplified metadata: Basically just a vtable + destructor + superclass pointer.
- Only non-resilient (intended as permanent restriction), non-generic classes (for now) supported.
- Relax the check that prohibits metadata emission and usage to allow classes.
Reformatting everything now that we have `llvm` namespaces. I've
separated this from the main commit to help manage merge-conflicts and
for making it a bit easier to read the mega-patch.
This is phase-1 of switching from llvm::Optional to std::optional in the
next rebranch. llvm::Optional was removed from upstream LLVM, so we need
to migrate off rather soon. On Darwin, std::optional, and llvm::Optional
have the same layout, so we don't need to be as concerned about ABI
beyond the name mangling. `llvm::Optional` is only returned from one
function in
```
getStandardTypeSubst(StringRef TypeName,
bool allowConcurrencyManglings);
```
It's the return value, so it should not impact the mangling of the
function, and the layout is the same as `std::optional`, so it should be
mostly okay. This function doesn't appear to have users, and the ABI was
already broken 2 years ago for concurrency and no one seemed to notice
so this should be "okay".
I'm doing the migration incrementally so that folks working on main can
cherry-pick back to the release/5.9 branch. Once 5.9 is done and locked
away, then we can go through and finish the replacement. Since `None`
and `Optional` show up in contexts where they are not `llvm::None` and
`llvm::Optional`, I'm preparing the work now by going through and
removing the namespace unwrapping and making the `llvm` namespace
explicit. This should make it fairly mechanical to go through and
replace llvm::Optional with std::optional, and llvm::None with
std::nullopt. It's also a change that can be brought onto the
release/5.9 with minimal impact. This should be an NFC change.
Deallocate dynamic allocas done for metadata/wtable packs. These
stackrestore calls are inserted on the dominance frontier and then stack
nesting is fixed up. That was achieved as follows:
Added a new IRGen pass PackMetadataMarkerInserter; it
- determines if there are any instructions which might allocate on-stack
pack metadata
- if there aren't, no changes are made
- if there are, alloc_pack_metadata just before instructions that could
allocate pack metadata on the stack and dealloc_pack_metadata on the
dominance frontier of those instructions
- fixup stack nesting
During IRGen, the allocations done for metadata/wtable packs are
recorded and IRGenSILFunction associates them with the instruction that
lowered. It must be the instruction after some alloc_pack_metadata
instruction. Then, when visiting the dealloc_pack_metadata instructions
corresponding to that alloc_pack_metadata, deallocate those packs.
Partially address the incorrect handling for the `#dsohandle` on
Windows.
We were previously emitting a local definition for this external
constant, and worse yet, not marking the definition for COMDAT. It is
unclear what definition would win ultimately (implementation defined),
as we had a definition as well as the linker synthesized value. We can
change the SIL linkage for this type to `DefaultForDeclaration` which
will give it `available_externally` and default visibility and storage
which is closer to what we desire. However, because we do not track the
LLVM variables and apply heuristics for lowering the
`SILGlobalVariable`, we would attribute it with imported DLL Storage.
This would then cause us to fail at link time (amusingly enough link.exe
will report a LNK1000). Special case the variable and track that we are
targeting a windows environment in the `UniversalLinkageInfo` so that we
do not special case this on other platforms.
This also has the nice side effect of allowing us to remove the special
case in the TBD handling.
Fixes: #64741
This removes the "optimization" where a function type, metatype or
tuple type was split up into structural components, because it seems
that in general we need this structural type metadata again.
Similarly, this no longer tries to split up dependent concrete
conformances and instead passes the witness table in the context.
This makes the context larger potentially, but it avoids calls to
metadata access functions and swift_getWitnessTable() every time the
closure is invoked.
A lot of the fixes here are adjustments to compensate in the
fulfillment and metadata-path subsystems for the recent pack
substitutions representation change. I think these adjustments
really make the case for why the change was the right one to make:
the code was clearly not considering the possibility of packs
in these positions, and the need to handle packs makes everything
work out much more cleanly.
There's still some work that needs to happen around type packs;
in particular, we're not caching them or fulfilling them as a
whole, and we do have the setup to do that properly now.
