Extracts the list of magic identifier literal kinds into a separate file and updates a lot of code to use macro metaprogramming instead of naming half a dozen cases manually. This is a complicated change, but it should be NFC.
Fix SILGen for `@derivative` attributes where the derivative generic signature
is equal to the original generic signature and has all concrete generic
parameters (i.e. all generic parameters are bound to concrete types via
same-type requirements).
SILGen should emit a differentiability witness with no generic signature.
This is already done for `@differentiable` attributes.
Resolves TF-1292.
Previously we would only link `.sib` partial
modules in SILGen, with other kinds of serialized
ASTs being linked just before the SILOptimizer if
`-sil-merge-partial-modules` was specified.
However linking them always seems to be the desired
behaviour, so adjust SILGen to link SIL for all
serialized AST inputs.
And also rename the underlying request and
descriptor.
This rename is motivated by the fact that the
operation may instead perform parsing of SIL files
and/or deserialization of SIB files.
Enum element constructors are used when an enum element satisfies
a protocol requirement. Instead of emitting them as part of
emitGlobalFunctionRef(), let's sink it down to getFunction() where
we do all other on-demand function body emission.
This mechanism is used for imported functions with bodies synthesized
by the ClangImporter, as well as on-demand accessors synthesized when
required for a protocol conformance (eg, a _read accessor, or a
_modify on a property whose opaque access pattern doesn't use a
_modify, such as an @objc dynamic property).
Previously this was intertwined with the 'delayed function' mechanism,
which is similar, but used for a different case -- implicit functions
inside the same translation unit.
Untangle these to allow further simplifications.
They both do essentially the same thing, with the
single-file request being the single-element case
of the whole-module request, with only the call to
`getAllForModule` really caring about the
difference.
Make derivative forwarding thunks use original function's linkage instead of the
derivative function's, stripping external.
This is consistent with the linkage of differentiability witnesses.
Clarify AutoDiff linkage-related comments.
Resolves TF-1160: TBDGen error due to incorrect derivative thunk linkage.
Adjust `SILModule::createEmptyModule` to accept a
FileUnit or ModuleDecl, and pass the corresponding
context for SIL generation and parsing. This
change means that SIL parsing will now correctly
use a SourceFile associated context when in
single-file mode.
Rather than eagerly parsing an input .sil file
in `performSemaUpTo`, trigger it from
`performSILGeneration`. This will allow us to
remove the SILModule stored on the
CompilerInstance and will eventually allow the
various SIL tools to just call into
`performSILGeneration` without needing to call
`performSema`.
This became necessary after recent function type changes that keep
substituted generic function types abstract even after substitution to
correctly handle automatic opaque result type substitution.
Instead of performing the opaque result type substitution as part of
substituting the generic args the underlying type will now be reified as
part of looking at the parameter/return types which happens as part of
the function convention apis.
rdar://62560867
When a type (class, enum, or struct) is annotated @main, it is required
to provide a function with the following signature:
static func main() -> ()
That function will be called when the executable the type is defined
within is launched.
Start fixing SR-12526: `@derivative` attribute cross-module deserialization
crash. Remove original `AbstractFunctionDecl *` from `DerivativeAttr` and store
`DeclID` instead, mimicking `DynamicReplacementAttr`.
A request is intended to be a pure function of its inputs. That function could, in theory, fail. In practice, there were basically no requests taking advantage of this ability - the few that were using it to explicitly detect cycles can just return reasonable defaults instead of forwarding the error on up the stack.
This is because cycles are checked by *the Evaluator*, and are unwound by the Evaluator.
Therefore, restore the idea that the evaluate functions are themselves pure, but keep the idea that *evaluation* of those requests may fail. This model enables the best of both worlds: we not only keep the evaluator flexible enough to handle future use cases like cancellation and diagnostic invalidation, but also request-based dependencies using the values computed at the evaluation points. These aforementioned use cases would use the llvm::Expected interface and the regular evaluation-point interface respectively.
Delete `@differentiable` attribute `jvp:` and `vjp:` arguments for derivative
registration. `@derivative` attribute is now the canonical way to register
derivatives.
Resolves TF-1001.
Generate SIL differentiability witnesses from `@differentiable` and
`@derivative` declaration attributes.
Add SILGen utilities for:
- Emiting differentiability witnesses.
- Creating derivative function thunks, which are used as entries in
differentiability witnesses.
When users register a custom derivative function, it is necessary to create a
thunk with the expected derivative type computed from the original function's
type. This is important for consistent typing and consistent differentiability
witness entry mangling.
See `SILGenModule::getOrCreateCustomDerivativeThunk` documentation for details.
Resolves TF-1138.
In order to allow this, I've had to rework the syntax of substituted function types; what was previously spelled `<T> in () -> T for <X>` is now spelled `@substituted <T> () -> T for <X>`. I think this is a nice improvement for readability, but it did require me to churn a lot of test cases.
Distinguishing the substitutions has two chief advantages over the existing representation. First, the semantics seem quite a bit clearer at use points; the `implicit` bit was very subtle and not always obvious how to use. More importantly, it allows the expression of generic function types that must satisfy a particular generic abstraction pattern, which was otherwise impossible to express.
As an example of the latter, consider the following protocol conformance:
```
protocol P { func foo() }
struct A<T> : P { func foo() {} }
```
The lowered signature of `P.foo` is `<Self: P> (@in_guaranteed Self) -> ()`. Without this change, the lowered signature of `A.foo`'s witness would be `<T> (@in_guaranteed A<T>) -> ()`, which does not preserve information about the conformance substitution in any useful way. With this change, the lowered signature of this witness could be `<T> @substituted <Self: P> (@in_guaranteed Self) -> () for <A<T>>`, which nicely preserves the exact substitutions which relate the witness to the requirement.
When we adopt this, it will both obviate the need for the special witness-table conformance field in SILFunctionType and make it far simpler for the SILOptimizer to devirtualize witness methods. This patch does not actually take that step, however; it merely makes it possible to do so.
As another piece of unfinished business, while `SILFunctionType::substGenericArgs()` conceptually ought to simply set the given substitutions as the invocation substitutions, that would disturb a number of places that expect that method to produce an unsubstituted type. This patch only set invocation arguments when the generic type is a substituted type, which we currently never produce in type-lowering.
My plan is to start by producing substituted function types for accessors. Accessors are an important case because the coroutine continuation function is essentially an implicit component of the function type which the current substitution rules simply erase the intended abstraction of. They're also used in narrower ways that should exercise less of the optimizer.
Creating a @_dynamicReplacement function requires the creation of a
reference to the original function. We need to call SILGenModule's
getFunction to satisfy all the assertions in place.
rdar://59774606
A keypath component for a stored property can take one of several forms:
- The property offset is known to be constant at compile-time.
This is used in the simplest cases for classes and structs.
- The property offset is not constant, but can be loaded from a global.
This is used for classes that require runtime resilient layout, but where
the offsets do not depend on the generic context.
- The property offset is not constant, and must be loaded from metadata.
This is the case where the offset depends on the generic context. Here,
we were only set up to load it from a fixed offset in the metadata.
This works for generic structs, or generic classes where the superclass
chain does not cross a resilience boundary.
However, if a resilience boundary is crossed, the offset of the field
offset in the metadata must itself be obtained at runtime by adding a
constant to a value loaded from a global. This case is not supported by
the current keypath ABI due to an oversight.
I filed <rdar://problem/59777983> to track extending the ABI to handle
this more elegantly in the future.
Fixes <rdar://problem/59617119>.
emitKeyPathComponentForDecl was only checking if the setter was
accessible from the current module, not the current function.
This failed when accessing an internal setter from a module
imported for testing.
emitKeyPathComponentForDecl was only checking if the setter was
accessible from the current module, not the current function.
This failed when accessing an internal setter from a module
imported for testing.
