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
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.
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
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
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