This adds initial support for differentiation of functions that may produce `Error` result.
Essentially we wrap the pullback into `Optional` and emit a diamond-shape control flow pattern depending on whether the pullback value is available or not. VJP emission was modified to accommodate for this. In addition to this, some additional tricks are required as `try_apply` result is not available in the instruction parent block, it is available in normal successor basic block.
As a result we can now:
- differentiate an active `try_apply` result (that would be produced from `do ... try .. catch` constructions)
- `try_apply` when error result is unreachable (usually `try!` and similar source code constructs)
- Support (some) throwing functions with builtin differentiation operators. stdlib change will follow. Though we cannot support typed throws here (yet)
- Correctly propagate error types during currying around differentiable functions as well as type-checking for `@derivative(of:)` attribute, so we can register custom derivatives for functions producing error result
- Added custom derivative for `Optional.??` operator (note that support here is not yet complete as we cannot differentiate through autoclosures, so `x ?? y` works only if `y` is not active, e.g. a constant value).
Some fixes here and there
Before this patch we referred to builtin names in SILGenBuiltin using raw c
strings. This can lead to potential spelling mistakes yielding bugs. Rather than
doing this, I stole a technique that we use in other parts of the compiler:
constexpr StringLiteral generation using CPP macros. Specifically, I defined in
Builtins.h a new namespace called BuiltinNames and inside of BuiltinNames I used
CPP macros to define a StringLiteral for each Builtin. Thus one can get the
appropriate name for a Builtin by writing:
```
BuiltinNames::Sizeof
```
instead of writing "Sizeof". I also cleaned up the code a little by adding for
functions that take identifiers an additional overload that takes a StringRef
and converts the StringRef to an identifier internally. This just eliminates
unnecessary code from call sites by moving them into the callee.
This is necessary because we need to model its stack-allocation
behavior, although I'm not yet doing that in this patch because
StackNesting first needs to be taught to not try to move the
deallocation.
I'm not convinced that `async let` *should* be doing a stack allocation,
but it undoubtedly *is* doing a stack allocation, and until we have an
alternative to that, we will need to model it properly.
Builtin.FixedArray was introduced as the first generic builtin type, with
special case handling in all the various recursive visitors. Introduce
a base class, and move the handling to that base class, so it is easier
to introduce other generic builtins in the future.
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>.
This is an NFC change. The idea is that this will make it easier to add new
BuiltinTypeKinds. I missed this code when adding Builtin.ImplicitIsolationActor.
By adding a covered switch, we can make sure this code is updated in the
future.
Ideally we'd be able to use the llvm interleave2 and deinterleave2
intrinsics instead of adding these, but deinterleave currently isn't
available from Swift, and even if you hack that in, the codegen from
LLVM is worse than what shufflevector produces for both x86 and arm. So
in the medium-term we'll use these builtins, and hope to remove them in
favor of [de]interleave2 at some future point.
It is like `zeroInitializer`, but does not actually initialize the memory.
It only indicates to mandatory passes that the memory is going to be initialized.
The builtin’s current is signature is:
```
(Any.Type, Any.Type) -> Bool
```
This needs to be changed to this:
```
(any (~Copyable & ~Escapable).Type, any (~Copyable & ~Escapable).Type) -> Bool
```
This requires a bit of support work in AST synthesis.
rdar://145707064
Co-authored-by: Alejandro Alonso <alejandro_alonso@apple.com>
Although it's not used anymore we still have to support it to be able to read old Swift.interface files which still contain the builtin.
rdar://144781646
`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.
Out of an abundance of caution, we:
1. Left in parsing support for transferring but internally made it rely on the
internals of sending.
2. Added a warning to tell people that transferring was going to
be removed very soon.
Now that we have given people some time, remove support for parsing
transferring.
rdar://130253724
Distributed actors can be treated as actors by accessing the `asLocalActor`
property. When lowering `#isolation` in a distributed actor initializer,
use a separate builtin `flowSensitiveDistributedSelfIsolation` to
capture the conformance to `DistributedActor`, and have Definite
Initialization introduce the call to the `asLocalActor` getter when
needed.
Actor initializers have a flow-sensitive property where they are isolated
to the actor being initialized only after the actor instance itself is
fully-initialized. However, this behavior was not being reflected in
the expansion of `#isolation`, which was always expanding to `self`,
even before `self` is fully formed.
This led to a source compatibility issue with code that used the async
for..in loop within an actor initializer *prior* to the point where the
actor was fully initialized, because the type checker is introducing
the `#isolation` (SE-0421) but Definite Initialization properly rejects
the use of `self` before it is initialized.
Address this issue by delaying the expansion of `#isolation` until
after the actor is fully initialized. In SILGen, we introduce a new
builtin for this case (and *just* this case) called
`flowSensitiveSelfIsolation`, which takes in `self` as its argument
and produces an `(any Actor)?`. Definite initialization does not treat
this as a use of `self`. Rather, it tracks these builtins and
replaces them either with `self` (if it is fully-initialized at this
point) or `nil` (if it is not fully-initialized at this point),
mirroring the flow-sensitive isolation semantics described in SE-0327.
Fixes rdar://127080037.
Although I don't plan to bring over new assertions wholesale
into the current qualification branch, it's entirely possible
that various minor changes in main will use the new assertions;
having this basic support in the release branch will simplify that.
(This is why I'm adding the includes as a separate pass from
rewriting the individual assertions)
TLDR: This makes it so that we always can parse sending/transferring but changes
the semantic language effects to be keyed on RegionBasedIsolation instead.
----
The key thing that makes this all work is that I changed all of the "special"
semantic changes originally triggered on *ArgsAndResults to now be triggered
based on RegionBasedIsolation being enabled. This makes a lot of sense since we
want these semantic changes specifically to be combined with the checkers that
RegionBasedIsolation turns on. As a result, even though this causes these two
features to always be enabled, we just parse it but we do not use it for
anything semantically.
rdar://128961672
We still only parse transferring... but this sets us up for adding the new
'sending' syntax by first validating that this internal change does not mess up
the current transferring impl since we want both to keep working for now.
rdar://128216574
A vestigial remnant of it was left behind after
06921cfe84 in order to avoid a reverse
condfail when building old swiftinterfaces that define
```swift
func _copy<T>(_ value: T) -> T {
#if $BuiltinCopy
Builtin.copy(value)
#else
value
#endif
}
```
If the language feature is removed, though, such interfaces should again
be buildable because the branch where the language feature isn't defined
should be expanded.
rdar://127516085
