Commit Graph

6 Commits

Author SHA1 Message Date
Michael Gottesman
cb2d7560a4 [rbi] Fix demangling of sending results.
The issue here is that the demangler (since we have a postfix mangling) parses
parameters/results/etc and then uses earlier postfix type arguments to attach
the relevant types to the parameters/results/etc. Since the flag for a sending
result was placed in between the parameters and results, we get an off by one
error.

Rather than fix that specific issue by introducing an offset for the off by one
error, I used the fact that the impl-function part of the mangling is not ABI
and can be modified to move the bit used to signify a sending result to before
the parameters so the whole problem is avoided.

I also while I was doing this looked through the sending result mangling for any
further issues and fixed them as I found them.

rdar://141962865
2025-01-14 15:38:02 -08:00
Alexander Cyon
7074c29bf3 [test/concurrency] Fix typos 2024-07-06 13:25:45 +02:00
Michael Gottesman
4d7af7be25 [sending] Make sending a no escape closure a default rather than consuming parameter
The reason why I am doing this is that:

1. We don't support no escaping closure parameters today and would like
   to leave the design space open.

2. These closures are bitwise copyable/trivial so marking them as
   specifically consuming doesn't really make sense.
2024-06-21 02:24:03 -07:00
Michael Gottesman
ce1dd43395 [sending] Change CheckedContinuation/AsyncThrowingStream.Continuation APIs to use sending parameters and results.
Specifically:

1. CheckedContinuation.resume now takes a sending parameter.
2. Async{Throwing,}Stream.yield takes a sending parameter.
3. withCheckedContinuation returns a transferring parameter.

Importantly due to the previous changes around mangling, this is a mangling
neutral change.

rdar://120420024
2024-06-01 23:25:16 -07:00
Michael Gottesman
a890c6011e [sending] Do not mangle shared into function signatures if they are paired with sending.
I am doing this b/c we are going to ban borrowing sending so that we can leave
open that space for further design. In the short term, we need the ability to
create +0 sending parameters without messing with mangling. By special casing
this, we get what we want.

rdar://129116141
2024-06-01 23:25:16 -07:00
Michael Gottesman
2bf497d131 [sending] Do not mangle sending into function/methods but keep mangling into vars/storage.
We want to ensure that functions/methods themselves do not have sending mangled
into their names, but we do want sending mangled in non-top level positions. For
example: we do not want to mangle sending into a function like the following:

```swift
// We don't want to mangle this.
func test(_ x: sending NonSendableKlass) -> ()
```

But when  it comes  to actually  storing functions  into memory,  we do  want to
distinguish in  between function values  that use sending  vs those that  do not
since we do not want to allow for  them to alias. Thus we want to mangle sending
into things like the following:

```swift
// We want to distinguish in between Array<(sending T) -> ()> and
// Array((T) -> ()>
let a = Array<(sending T) -> ()>

// We want to distinguish in between a global contianing (sending T) -> () and a
// global containing (T) -> ().
var global: (sending T) -> ()
```

This commit achieves that by making changes to the ASTMangler in getDeclType
which causes getDeclType to set a flag that says that we have not yet recursed
through the system and thus should suppress the printing of sendable. Once we
get further into the system and recurse, that flag is by default set to true, so
we get the old sending parameter without having to update large amounts of code.

rdar://127383107
2024-06-01 23:25:16 -07:00