We have an optimization in SILCombiner that "inlines" the use of compile-time constant key paths by performing the property access directly instead of calling a runtime function (leading to huge performance gains e.g. for heavy use of @dynamicMemberLookup). However, this optimization previously only supported key paths which solely access stored properties, so computed properties, optional chaining, etc. still had to call a runtime function. This commit generalizes the optimization to support all types of key paths.
When symbols are moved to this module, this module declares them as HIDE
for the OS versions prior to when the move happened. On the other hand, the
original module should declare ADD them for these OS versions. An executable
can choose the right library to link against depending on the deployment target.
This is a walk-around that linker directives cannot specify other install
name per symbol, we should eventually remove this.
Previously we had a request for this in
IDETypeChecking, but this wasn't used for queries
made from Sema. Move the request into Sema, and
move `hasDynamicMemberLookupAttribute` onto
TypeBase.
It must be consistent, otherwise the specialized function types may not match for calls in functions with different resilience expansions.
Fixes an assertion crash in the generic specializer.
rdar://problem/57844964
This is needed to build with VS2019:
```
swift\include\swift\AST\AutoDiff.h(172): error C2593: 'operator ==' is ambiguous
swift\include\swift\Basic\AnyValue.h(129): note: could be 'bool swift::operator ==(const swift::AnyValue &,const swift::AnyValue &)' [found using argument-dependent lookup]
swift\include\swift\AST\AutoDiff.h(172): note: or 'built-in C++ operator==(swift::AutoDiffDerivativeFunctionKind::innerty, swift::AutoDiffDerivativeFunctionKind::innerty)'
swift\include\swift\AST\AutoDiff.h(172): note: while trying to match the argument list '(const swift::AutoDiffDerivativeFunctionKind, const swift::AutoDiffDerivativeFunctionKind)'
```
The `@derivative` attribute registers a function as a derivative of another
function-like declaration: a `func`, `init`, `subscript`, or `var` computed
property declaration.
The `@derivative` attribute also has an optional `wrt:` clause specifying the
parameters that are differentiated "with respect to", i.e. the differentiation
parameters. The differentiation parameters must conform to the `Differentiable`
protocol.
If the `wrt:` clause is unspecified, the differentiation parameters are inferred
to be all parameters that conform to `Differentiable`.
`@derivative` attribute type-checking verifies that the type of the derivative
function declaration is consistent with the type of the referenced original
declaration and the differentiation parameters.
The `@derivative` attribute is gated by the
`-enable-experimental-differentiable-programming` flag.
Resolves TF-829.
Specifically:
1. I renamed the method insertAfter -> insertAfterInvocation and added an
ehaustive switch to ensure that we properly update this code if we add new apply
sites.
2. I added a new method insertAfterFullEvaluation that is like
insertAfterInvocation except that the callback is called with insertion points
after the end/abort apply instead of after the initial invocation of the
begin_apply.
Archiving expects to be able to instantiate generic classes by name. This previously worked if you had instantiated the specialization in question, because the ObjC runtime would be able to look it up. Now, if the name hasn't been created, Swift has to look it up. demangleObjCTypeName doesn't do generics, so this failed.
rdar://problem/57674583
All non cond_br SILInstructions are layout compatible with BranchPropagatedUser
since BPU just stores a PointerIntPair that leaves its low bits as zero unless
one adds a cond_br. Since in these cases, the SILInstructions are all not
cond_br, we can use this alternative API.
I also added some asserts to validate that the assumption that all such
SILInstructions are not cond_br is respected.
Otherwise it can happen that e.g. specialization runs between CrossModuleSerializationSetup and serialization, resulting that an inlinable function references a shared function (which doesn't have a public linkage).
The solution is to move serialization right after CrossModuleSerializationSetup. But only do that if cross-module-optimization is enabled (it would be a disruptive change to move serialization in general).
