HiddenType is a new TypeBase subclass that carries a mangled name
without leaking the actual type definition. It serves as a type-slot
placeholder for stored-property types that have been elided from a
serialized binary module, so that the client side can either
(1) resolve this mangled name to the real type if the client has access to the owning module, or
(2) use the mangled name as a key to query abstract layout information also serialized in the binary module.
As an example — a library with a hidden field of a bridging-imported type:
```
// Utility.h (internal bridging header)
// typedef struct { int value; } Wrapper;
public struct S {
private var w: Wrapper
public var weight: Double
}
In the serialized module, the client's view reconstructs as:
public struct S {
private var w: @_hidden("$sSo7Wrappera")
public var weight: Double
}
```
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.
Now that we have generalized existentials in Embedded Swift, we also
have all of the infrastructure for metatypes. They're lazily
constructed on an as-needed basis, but otherwise work the same way as
in non-Embedded Swift.
Fixes rdar://145706221.
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.
These will be used internally by the type checker to represent bindings
that are the joins and meets of types involving type variables. They
will not appear anywhere outside of the bindings code---so you won't
see them in expressions, or matchTypes(), etc.
Classes that use `@objc @implementation` should be treated exactly like native Objective-C classes. Among other things, this means that rather than the defining module exposing a public type metadata accessor for them, each client should emit its own hidden accessor.
Unfortunately, Swift has not been doing this correctly—the defining module may expose an accessor and any clients which know the class is objcImpl will use it. (Clients using a swiftinterface module, or a swiftmodule built from a swiftinterface, won’t know the class is objcImpl, but clients using the original swiftmodule file will know.) Because existing binaries may be calling this symbol, we can’t remove it, but we *can* at least stop using it.
performed, and simplify and improve the handling of allocation throughout
IRGen.
The improvements are that we used to use dynamic allocas in a few
places that clearly could and should use static allocas.
When compiling for a triple that predates typed throws,
`swift_getFunctionMetadataExtended` is conditionally available and emitted as a
weak external symbol. Previously, when such code ran on a older runtime where
`swift_getFunctionMetadataExtended` was uanvailable, accessing function metadata
for a `nonisolated(nonsending)` function would crash by invoking the null
`swift_getFunctionMetadataExtended`.
This patch adds a runtime null check when emitting metadata accessors for simple
`nonisolated(nonsending)` functions (those without typed throws or other
extended flags) in such situations. If `swift_getFunctionMetadataExtended` is
unavailable at runtime, we fall back to `swift_getFunctionMetadata`, returning
`@concurrent` function metadata instead.
This trade-off is acceptable because:
- Function metadata is not required to call a `nonisolated(nonsending)` function
- This enables use of these functions in frameworks like SwiftUI on older OS versions
Known limitations of the fallback path:
- Dynamic casts between `nonisolated(nonsending)` and `@concurrent` will incorrectly succeed
- Reflection will report `nonisolated(nonsending)` functions as `@concurrent`
- Existential erasure will lose the `nonisolated(nonsending)` attribute
These edge cases will produce obvious crashes during testing if misused, since
`nonisolated(nonsending)` expects its first parameter to be an actor while
`@concurrent` does not. This makes the increased compatibility worth the
trade-off.
rdar://158970802
We cannot use 'static' linkage for something that points into the
ASTContext, because there might be more than one ASTContext in a
single process.
Also, fix the spelling mistake in a related function name.
This is currently not wired up to anything. I am going to wire it up in
subsequent commits.
The reason why we are introducing this new Builtin type is to represent that we
are going to start stealing bits from the protocol witness table pointer of the
Optional<any Actor> that this type is bitwise compatible with. The type will
ensure that this value is only used in places where we know that it will be
properly masked out giving us certainty that this value will not be used in any
manner without it first being bit cleared and transformed back to Optional<any
Actor>.
Follow up to https://github.com/swiftlang/swift/pull/84635/.
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 the call to any such accessor is not correctly
annotated memory(none).
rdar://161606892
When building on Windows, if the nominal base type is in a non-static
library, we cannot reference the type descriptor directly. As a load is
required, we cannot statically initialise the pattern metadata. Account
for this in the addressability computation.
with sending results:
- The sending result mangling was added in the 6.0 runtime, so demangling
cannot be used to produce this metadata when targeting an earlier
runtime.
- The combination of a sending result with isolation requires the 6.1
runtime to successfully demangle, due to a bug in the 6.0 demangler.
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.
Remove `IRGenModule::useDllStorage()` as there is a standalone version
that is available and the necessary information is public from the
`IRGenModule` type. Additionally, avoid the wrapped `isStandardLibrary`
preferring to use the same method off of the public accessors. This
works towards removing some of the standard library special casing so
that it is possible to support both static and dynamic standard
libraries on Windows.
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
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.
Xi Ge
Doug Gregor
Pavel Yaskevich
Konrad Malawski
Slava Pestov
Becca Royal-Gordon
John McCall
Michael Gottesman
Michael Gottesman
Alejandro Alonso
Joe Groff
Arnold Schwaighofer
Nate Chandler
Anthony Latsis
Augusto Noronha
Saleem Abdulrasool
Pavel Yaskevich
Saleem Abdulrasool
Kuba Mracek
Allan Shortlidge