This adds support for calling virtual methods of C++ foreign reference types with static dispatch.
In C++, one can do:
```cpp
this->Base::virtualMethod()
```
Swift doesn't allow calling a particular overload of an overridden method, however, it allows calling an overload from the superclass with `super`:
```swift
extension Derived {
public func callSuper() {
return super.foo()
}
}
```
For inherited FRTs, the example above behaved in an unexpected way: the call would still be dispatched dynamically, despite using the syntax reserved for static dispatch. This change makes it behave similarly to pure-Swift classes.
rdar://177619427
This is specific to global-actor isolated functions because by default
async variants are `nonisolated(nonsending)` and won't switch
isolation.
If we are emitting a call to an `async` variant of an ObjC completion
handler API, we need to hop at the call site because there is no
`async` function that is going to hop in its body. Such calls are
referencing a sync variant with a special completion handler
synthesized the compiler and the isolation context has to be
established beforehand.
Resolves: rdar://164739199
Async variant of an ObjC API uses `get_async_continuation_addr`
so any hops have to happen before that. Currently this is no-op
because we don't emit a hop for isolated ObjC async variants but
that is changing.
When creating the SIL source location for a SourceLoc inside a macro
expansion, `getMagicFileIDString` traverses the `GeneratedSourceInfo` to
get the name of the parent source file. The call to
`getPresumedFileAndColumnForLoc` does not do this however, and instead
ends up using the line and column in the macro expansion buffer rather
than in the parent source file. Insert a call to
`getLocInOutermostSourceFile` (which `getMagicFileIDString` uses
internally) to make sure the file name and line number agree on the
source location.
rdar://177664640
AFAIR we were using the "enter task cancel cleanup" in async let to
cancel tasks, however this moved to enterAsyncLetCleanup. There is no
uses of the cancel cleanup anymore.
The Task.cancel was using the builtin, but the UnsafeCurrentTask.cancel
was using the normal rutime func, which the builtin would just end up
calling anyway.
I cna't see a reason to keep the builtin path, so let's remove this dead
code.
In `applyBorrowMutateAccessor()`, the self value was not being passed
to `getFnValue()` for class method dispatch. Fix this by correctly passing
the self value when it is required for dispatch similar to the call emission
of other accessors.
The biggest complexity here is dealing with the improper nesting of the
allocation for the argument, and I'm not very proud of the solution I found,
but for a one-off builtin, I think it'll work.
Previously an inner type only got the isolation but not `@Sendable`
when `GlobalActorIsolatedTypesUsability` is enabled, this is incorrect
because with the feature enabled global-actor isolation always implies
`@Sendable` for functions and closures.
Resolves: rdar://problem/171967902
This PR introduces implicit bridging from annotated smart pointers to
reference counted objects to Swift foreign reference types. The bridging
only happens when these smart pointers are passed around by value. The
frontend only sees the Swift foreign reference types in the signature
and the actual bridging happens during SILGen when we look at the
original clang types and note that they differ significantly from the
native types.
The bridging of parameters did not quite fit into the existing structure
of bridging conversions as smart pointers are non-trivial types passed
around as addresses and existing bridging conversions were implemented
for types passed directly.
rdar://156521316
In the context of coroutine/yielding accessors, "unwind" means
that the second half of the coroutine (code _after_ the `yield`
statement) will not run if an exception is thrown during the access.
Unwinding was the default behavor for legacy `_read`/`_modify` coroutine
accessors.
For the new `yielding borrow`/`yielding mutate` accessors, unwinding
was optional behind a separate feature flag.
But the final SE-0474 dictates that unwinding is always _disabled_ for
the new yielding accessors. That is, the new yielding accessors always
run to completion, regardless of whether there are thrown exceptions within
the access scope. This was deemed essential to ensure that authors of
data structures could guarantee consistency.
This PR permanently disables unwinding behavior for the new accessors.
The feature flag still exists but has no effect.
A handful of tests that verified the unwinding behavior have been
edited to ensure that unwinding does _not_ happen even when the feature
flag is specified.
This builtin only needs to be supported as the return of a borrow accessor,
so special case its handling as part of a storage expression in SILGenLValue.
Previously attempting to emit a thunk to wrap a throws(Never) function
within a non-throwing function would crash during SILGen because it was
unconditionally assumed the outer function had an error result. Change
this so that such cases instead create a try_apply and error branch as
they did before, but replace the rethrowing logic in the error branch
with an unreachable instruction.
This updates a large number of internal symbols, function names,
and types to match the final approved terminology. Matching the
surface language terminology and the compiler internals should
make the code easier for people to understand into the future.
We were creating the JumpDests too early, so lowering a 'break' or 'continue'
statement would perform cleanups that were recorded while evaluating the
pack expansion expression, which would cause SIL verifier errors and
runtime crashes.
- Fixes https://github.com/swiftlang/swift/issues/78598
- Fixes rdar://131847933
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.
Pavel Yaskevich
Egor Zhdan
Pavel Yaskevich
Henrik G. Olsson
Allan Shortlidge
Konrad `ktoso` Malawski
Meghana Gupta
Andrew Trick
Meghana Gupta
Benjamin Levine
Elsa Keirouz
Kavon Farvardin
Jamie
John McCall
Gábor Horváth
Gabor Horvath
Joe Groff
elsa
Tim Kientzle
Slava Pestov
Adrian Prantl
Hamish Knight