This feature allows the following construct to work:
protocol P1 {
associatedtype T : P1
}
protocol P2 {
associatedtype T : P2
}
func foo<T : P1 & P2>(_: T) {}
However, I haven't figured out how to make it work with rewrite system
minimization, so it's already disabled when you use the requirement
machine for protocol or generic signature minimization. In addition to
that it adds some complexity.
I haven't found any real-world uses of this pattern yet, so I'm going
to try to turn it off, and if nobody complains, remove the support
altogether.
If people do complain, we'll have to figure out how to make it work with
minimization.
Repurpose mangling operator `Y` as an umbrella operator that covers new attributes on function types. Free up operators `J`, `j`, and `k`.
```
async ::= 'Ya' // 'async' annotation on function types
sendable ::= 'Yb' // @Sendable on function types
throws ::= 'K' // 'throws' annotation on function types
differentiable ::= 'Yjf' // @differentiable(_forward) on function type
differentiable ::= 'Yjr' // @differentiable(reverse) on function type
differentiable ::= 'Yjd' // @differentiable on function type
differentiable ::= 'Yjl' // @differentiable(_linear) on function type
```
Resolves rdar://76299796.
The TypeDecoder logic had a bug that caused crashes when it saw a tuple type with a variadic marker. Since variadic tuples aren't supported, this changes the logic to cleanly reject a tuple with a variadic marker.
Our mangling did not encode if an Objective-C block was escaping or
not. This is not a huge problem in practice, but for debug info we
want type reconstruction to round-trip exactly. There was a previous
workaround to paper over this specific problem.
Remove the workaround, and add a new 'XL' mangling for escaping
blocks. Since we don't actually want to break ABI compatibility,
only use the new mangling in DWARF debug info.
Check the availability of decls that declare an opaque return type to ensure they deploy to a
runtime that supports opaque types.
rdar://problem/50731151
Error structs synthesized by ClangImporter can be renamed using SWIFT_NAME() to syntactically appear anywhere in the type hierarchy with any name, but they should always be mangled as `__C_Synthesized.related decl ‘e’ of <Objective-C enum name>`. Unforunately, when SWIFT_NAME() was used to nest the error struct inside another type, an ASTMangler bug would cause it to be mangled as `<parent type>.related decl ‘e’ of <Objective-C enum name>`, and an ASTDemangler bug would also require a valid parent type. This created a mismatch between the compiler’s and runtime’s manglings which caused crashes when you tried to match the imported error struct in a `catch`.
This PR corrects the compiler bugs so that it generates the mangling the runtime expects. This is theoretically ABI-breaking, but as far as I can determine nobody has shipped the incorrectly mangled names, presumably because they crash when you try to use them.
Fixes <rdar://problem/48040880>.
MetadataLookup gives special treatment to imported Objective-C classes,
since there's no nominal type descriptor and metadata is obtained
directly by calling into the Objective-C runtime.
Remote reflection also gives special treatment to imported Objective-C
classes; they don't have field descriptors.
However, the ASTDemangler needs to treat them like ordinary classes,
in particular it wants to preserve the generic arguments here so that
we can round-trip debug info.
If we nest a type inside a local context inside a generic type,
we have to look through the local context(s) to find the outer
generic type when stripping off generic arguments.
We don't support nominal types inside generic local context
right now, but this can happen with type aliases.
Debug info uses a special mangling where type aliases can be
represented without being desugared; attempt to reconstruct
the TypeAliasType in this case.
It's clever how it leverages the type checker to check generic arguments,
but calling checkGenericArguments() would have been simpler, and it doesn't
work for interface types anyway, so we would fail to demangle those.
Let's just cut this all out for now and build a BoundGenericType directly.
