* Move differentiability kinds from target function type metadata to trailing objects so that we don't exhaust all remaining bits of function type metadata.
* Differentiability kind is now stored in a tail-allocated word when function type flags say it's differentiable, located immediately after the normal function type metadata's contents (with proper alignment in between).
* Add new runtime function `swift_getFunctionTypeMetadataDifferentiable` which handles differentiable function types.
* Fix mangling of different differentiability kinds in function types. Mangle it like `ConcurrentFunctionType` so that we can drop special cases for escaping functions.
```
function-signature ::= params-type params-type async? sendable? throws? differentiable? // results and parameters
...
differentiable ::= 'jf' // @differentiable(_forward) on function type
differentiable ::= 'jr' // @differentiable(reverse) on function type
differentiable ::= 'jd' // @differentiable on function type
differentiable ::= 'jl' // @differentiable(_linear) on function type
```
Resolves rdar://75240064.
While it is very convenient to default the ExtInfo state when creating
new function types, it also make the intent unclear to those looking to
extend ExtInfo state. For example, did a given call site intend to have
the default ExtInfo state or does it just happen to work? This matters a
lot because function types are regularly unpacked and rebuilt and it's
really easy to accidentally drop ExtInfo state.
By changing the ExtInfo state to an optional, we can track when it is
actually needed.
Compiler:
- Add `Forward` and `Reverse` to `DifferentiabilityKind`.
- Expand `DifferentiabilityMask` in `ExtInfo` to 3 bits so that it now holds all 4 cases of `DifferentiabilityKind`.
- Parse `@differentiable(reverse)` and `@differentiable(_forward)` declaration attributes and type attributes.
- Emit a warning for `@differentiable` without `reverse`.
- Emit an error for `@differentiable(_forward)`.
- Rename `@differentiable(linear)` to `@differentiable(_linear)`.
- Make `@differentiable(reverse)` type lowering go through today's `@differentiable` code path. We will specialize it to reverse-mode in a follow-up patch.
ABI:
- Add `Forward` and `Reverse` to `FunctionMetadataDifferentiabilityKind`.
- Extend `TargetFunctionTypeFlags` by 1 bit to store the highest bit of differentiability kind (linear). Note that there is a 2-bit gap in `DifferentiabilityMask` which is reserved for `AsyncMask` and `ConcurrentMask`; `AsyncMask` is ABI-stable so we cannot change that.
_Differentiation module:
- Replace all occurrences of `@differentiable` with `@differentiable(reverse)`.
- Delete `_transpose(of:)`.
Resolves rdar://69980056.
Since these types have an implicit stored property, this requires
adding an abstraction over fields to IRGen, at least throughout
the class code. In some ways I think this significantly improves
the code, especially in how we approach missing members.
Fixes rdar://72202671.
When emitting the metadata accessor for a generic type for which
canonical prespecialized metadata records have been formed, rather than
calling getGenericMetadata, instead call
getCanonicalPrespecializedGenericMetadata and pass to it the once token
which will guard that the canonical prespecialized metadata records
attached to the nominal type descriptor are only added to the metadata
cache once.
Previously, the metadata accessor for which canonical prespecializations
had been formed included checks against the passed-in arguments to
determine whether the access matched a prespecialized record or not.
Now that the prespecialized records are attached to the nominal type
descriptor for the type, eliminate this hard-coded generated code and
instead let swift_getGenericMetadata do the work of looking through the
prespecializations.
Previously, noncanonical records were only allowed if one of the
arguments was from the module where the record was to be emitted.
Here, that restriction is lifted. Now getSpecializedGenericMetadata
will, on first run, register all canonical metadata with the global
cache before attempting to bless the passed-in noncanonical record,
allowing noncanonical records to be for the same arguments as a
canonical record (since in the case that a canonical record does exist,
it will be returned).
The metadata accessor and type context descriptor for a nominal type
both depend on canonical metadata--the former because it returns those
metadata, the latter because it has them as trailing objects.
Here, the work is done to reemit those values when new canonical
prespecialized metadata are encountered.
several more places to use getOrCreateHelperFunction.
This means that several of these places are now emitting
shared functions rather than private ones, which I've
verified is okay. There are some other places where
privacy is still unfortunately necessary.
I've also fixed the name of the store-extra-inhabitants
helper function to say "store" instead of "get", which
is longstanding (but harmless because it's private).
Fixes rdar://66707994.
Add `async` to the type system. `async` can be written as part of a
function type or function declaration, following the parameter list, e.g.,
func doSomeWork() async { ... }
`async` functions are distinct from non-`async` functions and there
are no conversions amongst them. At present, `async` functions do not
*do* anything, but this commit fully supports them as a distinct kind
of function throughout:
* Parsing of `async`
* AST representation of `async` in declarations and types
* Syntactic type representation of `async`
* (De-/re-)mangling of function types involving 'async'
* Runtime type representation and reconstruction of function types
involving `async`.
* Dynamic casting restrictions for `async` function types
* (De-)serialization of `async` function types
* Disabling overriding, witness matching, and conversions with
differing `async`
When a generic type from a different module is not resilient within the
current module and at least one of its arguments is from the current
module, emit a non-canonical prespecialized record, and access that
metadata via a call to swift_getCanonicalSpecializedMetadata, passing in
the non-canonical record.
rdar://problem/56996727
rdar://problem/56997022
Two protocol conformance descriptors are passed to
swift_compareProtocolConformanceDecriptors from generic metadata
accessors when there is a canonical prespecialization and one of the
generic arguments has a protocol requirement.
Previously, the descriptors were incorrectly being passed without
ptrauth processing: one from the witness table in the arguments that are
passed in to the accessor and one known statically.
Here, the descriptor in the witness table is authed using the
ProtocolConformanceDescriptor schema. Then, both descriptors are signed
using the ProtocolConformanceDescriptorsAsArguments schema. Finally, in
the runtime function, the descriptors are authed.
Previously, the metadata accessor for a generic type for which some
metadata prespecialization was done only tested that the type metadata
arguments were equal to those of the prespecialization. If the generic
type had an argument which was constrained to conform to a protocol, the
particular conformance to that protocol was determined at compile time,
but the conformance was ignored in the metadata accessor. As a result
it was possible--in certain multi-module cases--for the metadata
accessor to incorrectly return a prespecialized metadata record whose
type arguments matched the type arguments passed to the accessor but
whose conformance arguments did not.
For example, given the following,
Base:
struct K {}
protocol P {}
Conformance1:
import Base
struct G<T : P> {}
extension K : P {} // first conformance
prespecialize( G<K>.self )
Conformance2:
import Base
extension K : P {} // second conformance
the metadata accessor for G defined in Conformance1 would behave like
MetadataResponse `metadata accessor for G`(
MetadataRequest request,
const Metadata *M,
const WitnessTable *WT) {
if (M == `type metadata for K`) {
return `canonical prespecialized type metadata for G<K>`
}
return swift_getGenericMetadata(request, {M, WT});
}
Here, the WitnessTable argument is the witness table describing a
conformance of the type whose metadata is provided to the protocol P.
The incorrect behavior occurs when calling the metadata accessor with
these arguments:
`some request`
`type metadata for K`
`protocol witness table for Base.K : Base.P in Conformance2`
The accessor would return the `canonical prespecialized type metadata
for G<K>`. The problem is that the prespecialized metadata contains the
following generic arguments:
`type metadata for K`
`protocol witness table for Base.K : Base.P in Conformance1`
Specificallly, the witness table is for the conformance from
Conformance1, not the conformance from Conformance2.
Here, the problem is addressed by testing that the witness tables passed
into the accessor are for the same conformance as the witness table
referred to by the prespecialized record. Now, the metadata accessor
for G will behave like
MetadataResponse `metadata accessor for G`(
MetadataRequest request,
const Metadata *M,
const WitnessTable *WT) {
if (M == `type metadata for K`
swift_compareProtocolConformanceDescriptors(
WT->getDescription(),
`protocol conformance descriptor for Base.K : Base.P in Conformance1`)
) {
return `canonical prespecialized type metadata for G<K>`
}
return swift_getGenericMetadata(request, {M, WT});
}
Consequently, when the accessor is called with the same arguments as
before, the call to swift_compareProtocolConformanceDescriptors will
return false and the non-matching prespecialized metadata will not be
returned.
Previously, metadata prespecialization for classes only occurred when
all of a specialized generic class's ancestors were themselves generic.
Here, that requirement is lifted so that generic classes with concrete
ancestors are also eligible for prespecialization.
Previously a bool argument was passed to
isCanonicalSpecializedNominalTypeMetadataStaticallyAddressable to
indicate whether the metadata was to be used only from a specialized
metadata accessor. Here, that bool is replaced with an enum.
When generic metadata for a class is requested in the same module where
the class is defined, rather than a call to the generic metadata
accessor or to a variant of typeForMangledNode, a call to a new
accessor--a canonical specialized generic metadata accessor--is emitted.
The new function is defined schematically as follows:
MetadataResponse `canonical specialized metadata accessor for C<K>`(MetadataRequest request) {
(void)`canonical specialized metadata accessor for superclass(C<K>)`(::Complete)
(void)`canonical specialized metadata accessor for generic_argument_class(C<K>, 1)`(::Complete)
...
(void)`canonical specialized metadata accessor for generic_argument_class(C<K>, count)`(::Complete)
auto *metadata = objc_opt_self(`canonical specialized metadata for C<K>`);
return {metadata, MetadataState::Complete};
}
where generic_argument_class(C<K>, N) denotes the Nth generic argument
which is both (1) itself a specialized generic type and is also (2) a
class. These calls to the specialized metadata accessors for these
related types ensure that all generic class types are registered with
the Objective-C runtime.
To enable these new canonical specialized generic metadata accessors,
metadata for generic classes is prespecialized as needed. So are the
metaclasses and the corresponding rodata.
Previously, the lazy objc naming hook was registered during process
execution when the first generic class metadata was instantiated. Since
that instantiation may occur "before process launch" (i.e. if the
generic metadata is prespecialized), the lazy naming hook is now
installed at process launch.
Clang provides options to override that default value.
These options are accessible via the -Xcc flag.
Some Swift functions explicitly disable the frame pointer.
The clang options will not override those.
Previously, prespecialization was incorrectly being performed for
non-resilient types defined by other modules. This is incorrect for
statically canonical metadata records because in order to be canonical,
they need to be returned from the metadata accessor which is emitted by
the module which defines the type.
Without whole module optimization, the metadata accessors are emitted on
a per-file basis. The result is that if the file containing a generic
type is processed before the file containing a usage of that type that
would result in that prespecialization, the metadata accessor would have
already been emitted by the time that the usage is noted, making it
impossible for the newly created prespecialization to be returned from
the already-emitted metadata accessor.
Here, require that either whole module optimization is enabled so that
the metadata accessors are all emitted at once at the end, or else that
the usage of the prespecialization is in the same file as the type is
declared.
Add mangling scheme for `@differentiable` and `@differentiable(linear)` function
types. Mangling support is important for debug information, among other things.
Update docs and add tests.
Resolves TF-948.
The only initialization these class objects need is ObjC realization, which can be done
fast with `objc_opt_self` on recent Apple OSes. The cache check just adds code size and
dirties memory.
Some metadata may require instantiation, but not in a way that requires us to put an additional
cache layer in front of it. `Self` metadata is also trivial to access from the local cache, but
isn't statically referenceable. Split these concepts and update code to use one or the other
appropriately. This catches an issue with metadata prespecialization where it would try to
make records for dynamic `Self` incorrectly.
