Conflicts:
- `test/Interop/Cxx/class/method/methods-this-and-indirect-return-irgen-itanium.swift`
previously fixed on rebranch, now fixed on main (slightly differently).
This corresponds to the parameter-passing convention of the Itanium C++
ABI, in which the argument is passed indirectly and possibly modified,
but not destroyed, by the callee.
@in_cxx is handled the same way as @in in callers and @in_guaranteed in
callees. OwnershipModelEliminator emits the call to destroy_addr that is
needed to destroy the argument in the caller.
rdar://122707697
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
Previously we would mangle a single ErrorType as
the type for the element, but that would fail to
demangle since we expect a function type. Use the
same logic as AbstractFunctionDecl, mangling a
function type of ErrorType. While here, also
handle SubscriptDecls and check for error types
rather than `isInvalid()`.
rdar://129065620
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)
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
