My previous fix in `6f6a46f` was the correct fix in theory, but in
practice it could accidentally change the mangling of something I
haven't considered, which would break ABI with Swift 6.0
I've narrowed that fix here to only affect dependent conformances
specifically for Copyable/Escapable. The existing code in
`appendDependentProtocolConformance` would always reach a trap because
we're mangling a conformance path that ends with Copyable/Escapable.
We can assume no such symbol has been successfully been mangled before,
thanks to the pre-existing skip in `conformanceRequirementIndex`, so
there's no risk of ABI change.
rdar://135310019
Typically, a conformance that is dependent on a conformance to a marker
protocol never reaches this point in the compiler, where we're mangling
the metadata for an opaque return type.
But with the invertible protocols like Copyable, we do permit them, so
we should avoid mangling Copyable as that's generally ABI incompatible
with existing code.
resolves rdar://135310019
Mangling this information for future directions like component lifetimes
becomes complex and the current mangling scheme isn't scalable anyway.
Deleting this support for now.
Some requirement machine work
Rename requirement to Value
Rename more things to Value
Fix integer checking for requirement
some docs and parser changes
Minor fixes
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
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
The mangled name produced for the debugger should match the one emitted
in reflection metadata, otherwise LLDB will not be able to lookup types
when the module is compiled with the -module-abi-name flag.
rdar://125848324
