A recent PR (#77204) started to import C++ source locations into Swift.
This PR flips a switch so these locations are actually used more widely.
Now some of the diagnostic locations are changed, but they generally
improved the quality of the diagnostics, pointing out conformances
imported from Obj-C code right when they are declared.
Today ParenType is used:
1. As the type of ParenExpr
2. As the payload type of an unlabeled single
associated value enum case (and the type of
ParenPattern).
3. As the type for an `(X)` TypeRepr
For 1, this leads to some odd behavior, e.g the
type of `(5.0 * 5).squareRoot()` is `(Double)`. For
2, we should be checking the arity of the enum case
constructor parameters and the presence of
ParenPattern respectively. Eventually we ought to
consider replacing Paren/TuplePattern with a
PatternList node, similar to ArgumentList.
3 is one case where it could be argued that there's
some utility in preserving the sugar of the type
that the user wrote. However it's really not clear
to me that this is particularly desirable since a
bunch of diagnostic logic is already stripping
ParenTypes. In cases where we care about how the
type was written in source, we really ought to be
consulting the TypeRepr.
When looking up the decl context of a type, ASTDemangler has to take
into account that there are multiple different modules where that type
could've come from. This is due to two facts:
- Thanks to the `-module-abi-name` flag, multiple modules can share
the same ABI name (which is the module name that is usually used when
mangling a type).
- In some situations mangling can use the module's real name, for
example, when mangling for the debugger or USRs coupled with @_originallyDefinedIn.
rdar://134095412
A type's mangled name will store the module's ABI name, not the module's
regular name. When reconstructing a type from a mangled name, the
demangler needs to take that into account.
rdar://126953614
It's not clear that its worth keeping this as a
base class for SerializedAbstractClosure and
SerializedTopLevelCodeDecl, most clients are
interested in the concrete kinds, not only whether
the context is serialized.
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.
