rdar://163631865
Under certain circumstances the same symbol can be used for different implementations of the forwarders.
The forwarders themselves are already emitted with "internal" LLVM linkage, but some particularities in
the mapping from SILLinkage to LLVM linkage caused async function pointers to partial apply forwarders
to be emitted with linkonce_odr instead, which caused the wrong forwarder to be called at runtime, causing
unexpected behavior and crashes.
As the above comments imply, when isTypeKind() returns true, then
getType() should return a valid Type. This wasn't true with
DifferentiabilityWitness.
When generating dead stub methods for vtable entries, we should not
attach COMDATs to their definitions. This is because such stubs may be
referenced only through aliases, and the presence of a COMDAT on the
stub definition would cause the aliased symbol, we want to keep, to be
discarded from the symbol table when other object files also have a
dead stub method.
Given the following two object files generated:
```mermaid
graph TD
subgraph O0[A.swift.o]
subgraph C0[COMDAT Group swift_dead_method_stub]
D0_0["[Def] swift_dead_method_stub"]
end
S0_0["[Symbol] swift_dead_method_stub"] --> D0_0
S1["[Symbol] C1.dead"] --alias--> D0_0
end
subgraph O1[B.swift.o]
subgraph C1[COMDAT Group swift_dead_method_stub]
D0_1["[Def] swift_dead_method_stub"]
end
S0_1["[Symbol] swift_dead_method_stub"] --> D0_1
S2["[Symbol] C2.beef"] --alias--> D0_1
end
```
When linking these two object files, the linker will pick one of the
COMDAT groups of `swift_dead_method_stub`. The other COMDAT group will be
discarded, along with all symbols aliased to the discarded definition,
even though those aliased symbols (`C1.dead` and `C2.beef`) are the
ones we want to keep to construct vtables.
This change stops attaching COMDATs to dead stub method definitions.
This effectively only affects WebAssembly targets because MachO's
`supportsCOMDAT` returns false, and COFF targets don't use
`linkonce_odr` for dead stub methods.
The COMDAT was added in 7e8f782457
Removes the underscored prefixes from the @_section and @_used attributes, making them public as @section and @used respectively. The SymbolLinkageMarkers experimental feature has been removed as these attributes are now part of the standard language. Implemented expression syntactic checking rules per SE-0492.
Major parts:
- Renamed @_section to @section and @_used to @used
- Removed the SymbolLinkageMarkers experimental feature
- Added parsing support for the old underscored names with deprecation warnings
- Updated all tests and examples to use the new attribute names
- Added syntactic validation for @section to align with SE-0492 (reusing the legality checker by @artemcm)
- Changed @DebugDescription macro to explicitly use a tuple type instead of type inferring it, to comply with the expression syntax rules
- Added a testcase for the various allowed and disallowed syntactic forms, `test/ConstValues/SectionSyntactic.swift`.
The metadata accessor for a variadic generic type takes as arguments
packs of metadata records and witness tables, and each such pack is
passed in a buffer. So any such accessor is not correctly annotated
`memory(none)`.
rdar://161606892
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.
