The VWT flags for isNonCopyable aren't always being set
correctly by the runtime when it is creating type metadata.
We can't always set them correctly, in the case of fixed-layout
types, as their VWT is static and read-only, yet could still be
conditionally copyable. For example:
```
struct FactoryOf<T: ~Copyable>: ~Copyable {
var counter: Int = 0
}
extension FactoryOf: Copyable where T: Copyable {}
```
In the common case of an unconditionally Copyable type, we do
effectively two quick bit-tests: one to see if the VWT thinks
it "could be Copyable" and then delegate to
`checkInvertibleRequirements` which has a fast-path for types
that are unconditionally Copyable by checking some bits in the
type's context descriptor.
related to rdar://176282041
The code generation model for a particular declaration or conformance
can be defined explicitly with `@export(interface)`,
`@export(implementation)`, or `@inlinable` (for declarations),
indicating where the definition will occur.
Embedded Swift also has some limitations on what can be emitted into
IR. For example, a generic function cannot be `@export(interface)`
because Embedded Swift does not support unspecialized generics.
Compute the effective code generation model based on what was
explicitly specified, the limitations of the model, and the default
code generation model for the given module, which defaults to
"inlinable" but can be made "implementation" by the DeferredCodeGen
feature. Use the effective code generation model for IR- and SIL-level
determinations of linkage and where to emit symbols.
[WIP] Start computing and using the "effective" code generation model
FIXUP linkage of the alias symbol
@export(interface) makes it so that Embedded Swift will emit a strong
definition of a symbol in its defining module, and use that symbol in
other modules. Extend this notion to non-generic types, where we will
emit a strong definition for the full type metadata, and let it be
referenced from other modules rather than the lazy, shared emission.
Implements rdar://176392354.
The Embedded Swift dynamic casting logic was getting a bit tangled, and
used some heuristics for figuring out the existential representation
that didn't always work, e.g., with class-bound types.
Reimplement the entire thing using the same general approach that the
non-Embedded runtime uses, albeit simplified greatly because Embedded
Swift doesn't permit casting to existential types (only *from*
existential types). The new implementation correctly unwraps all levels
of existential, short-circuits where appropriate, and "takes" wherever
possible.
This change does require emitting some more metadata than we did
before, because it is necessary to handle the different existential
representations correctly. Previously, the compiler would pass a NULL
pointer as the "source" metadata to `swift_dynamicCast`, then try to
figure out what it was given by inspecting the source pointer. This is
insufficient for distinguishing the various existential representations
(opaque, class-bound, error) and relied on heuristics. Start passing
destination metadata to this function, just as we do in non-Embedded
Swift. This means we'll end up generating some more metadata for
existential types (like `any P`) that we wouldn't have before, but
it's still pay-per-use and they are relatively small. All of the other
metadata that can flow here will already have been created for other
reasons, e.g., because classes already have it in their vtable.
This also extends the metadata associated with existential types by one
more word (from 2 to 3). The new word is used to provide the
existential representation, which is needed for dynamic casting as
described above.
Following the emission of metadata for tuple and function types, also
lazily emit (sparse) metadata for metatype and existential types. This
is needed when forming existential values.
Support for existentials in Embedded Swift has been available for a
little while now and appears to be solid. Remove the ability to disable
them (via `-disable-experimental-feature EmbeddedExistentials`), both
because it simplifies the code and because it's an ABI break to
disable the feature.
The protocol conformance descriptor passed to swift_getWitnessTable
needs to be signed on arm64e. When reparenting a protocol P with
new parent Q, we emit a small "default conformance accessor" function
that instantiates the type's witness table for Q using its witness
table for P, at runtime. This accessor is only used if the type
conforming to P comes from a module that hasn't been rebuilt since
the reparenting happened.
resolves rdar://171661924
We don't need to export the type metadata address point alias in clients that
lazily emit other module's type metadata. There will be an exported
metadata symbol in the originating module for that purpose.
Instead, satisfy any local uses of the metadata address point uses by its
underlying address computation.
This is to workaround a bug where LLVM generates the wrong assembly for
weak aliases that point to an offset of another symbol.
```
@"$e1C7MyClassCySiGN" = weak_odr hidden alias %swift.type, getelementptr
inbounds (<{ ptr, ptr, ptr, ptr, ptr, ptr, ptr, ptr, ptr, ptr, ptr }>,
ptr @"$e1C7MyClassCySiGMf", i32 0, i32 1)
```
Generates:
```
.weak_reference _$e1C7MyClassCySiGN
.private_extern _$e1C7MyClassCySiGN
.alt_entry _$e1C7MyClassCySiGN
_$e1C7MyClassCySiGN = _$e1C7MyClassCySiGMf+8
```
Instead of
```
.weak_definition _$e1C7MyClassCySiGN
.private_extern _$e1C7MyClassCySiGN
.alt_entry _$e1C7MyClassCySiGN
_$e1C7MyClassCySiGN = _$e1C7MyClassCySiGMf+8
```
Leading for "weak"ness to be ignored and duplicate type medata symbol linkage
errors.
rdar://169573918
This change forces you to write ``@reparented` relationships
on an extension of a protocol, rather than on the protocol
itself.
The ProtocolConformance needs to be associated with some
GenericContext and IRGen expects it to be an ExtensionDecl.
That environment defines under what conditions the conformance
exists. We also need to define witnesses for the new parent's
requirements in an extension anyway, so it's a natural fit.
The previous workaround for this was kind of awful, as it'd
require searching all the protocol's extensions and "guess"
which extension they want to represent the conformance. While
we could try to synthesize an extension, there's two
challenges there:
1. Due to SuppressedAssociatedTypes, it's not so simple to
synthesize an unconstrained ExtensionDecl.
2. We currently rely on same-type requirements to pin the
associated types to particular witnesses of those requirements
in the extension. So it's not purely unconstrained! For example,
```
extension Seq: @reparented BorrowSeq where Iter == MyIter {}
```
The constraints that are disallowed (but not yet diagnosed)
are conditional conformance requirements, as the default
conformance for a reparenting cannot depend on those.
Thus, it's better that programmers to specify the extension.
Changing runtime in anyway can effect backward deployability.
Treeat borrow and mutate accessors as a regular method since they don't need any differentiated
runtime handling.
This updates a large number of internal symbols, function names,
and types to match the final approved terminology. Matching the
surface language terminology and the compiler internals should
make the code easier for people to understand into the future.
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
Anonymous structs cannot be copied or moved, these operations only can
happen to their enclosing non-anonymous types. Stop trying to emit
special member functions and value witness tables for these structs.
rdar://157795547
When types contain stored properties of resilient types, we instantiate their metadata at runtime. If those types are non-copyable, they won't have layout strings, so we must not set the flag.
This enables the use of reference-counted foreign reference types on Windows. As it turns out, the assertion that was failing on Windows previously was unnecessary. This also enabled many of the tests on Windows.
rdar://154694125 / resolves https://github.com/swiftlang/swift/issues/82643
Conditionally available opaque return types should support availability
conditions that are evaluated in any availability domain. Update
`ConditionallyAvailableSubstitutions` to model its conditions with
`AvailabilityQuery` instead of assuming that conditions are always a single
version query for the current platform.
This reverts a revert that was done internally here https://stashweb.sd.apple.com/projects/DEVTOOLS/repos/swift/pull-requests/8697/overview
and corrects some issues with the reverted code while at it.
This fix is crucial to land for correctness and necessary to fix the
rdar://144568615 which had a fix submitted however that assumed that
THIS change also was present, so the fix submitted for 144568615 is
incomplete without this change as well.
This enables, and adds more TBD testing and was explicitly checked
against the GameKit reproducer project from rdar://144568615.
I will also upstream the necessary parts missing from OSS repo there so
we have alignment between all branches.
rdar://153681688
Instead fo counting the actual conformances, the logic took the size of the bit field, i.e. used the highest set bit, so when a type had a conditional conformance only on ~Escapable, but not on ~Copyable, it would still add 2 placeholders, but only fill one.
Kavon Farvardin
Doug Gregor
susmonteiro
Guillaume Lessard
Erik Eckstein
Elsa Keirouz
Arnold Schwaighofer
Dario Rexin
Meghana Gupta
Tim Kientzle
Slava Pestov
Nate Chandler
nate-chandler
Ellis Hoag
John McCall
Gábor Horváth
Gabor Horvath
Egor Zhdan
Allan Shortlidge
Anthony Latsis
Konrad 'ktoso' Malawski