This is a crucial fix without which we can crash on some distributed
protocol declarations with @Resolvable. We cannot "just" use a String to
represent the "fake base" of the thunks, and must instead find the
$Target macro generated type and use it as the base of the thunk's
mangling.
Calls are made in such way that record for the protocol requirement:
`$s4main28GreeterDefinedSystemProtocolP5greetSSyYaKFTEHF` points at
`$$s4main29$GreeterDefinedSystemProtocolC5greetSSyYaKFTE` which makes a
dispatch through the _apropriate_ witness table.
And the record for the $witness named e.g.
`$s4main29$GreeterDefinedSystemProtocolC5greetSSyYaKFTEHF` points to
`$s4main28GreeterDefinedSystemProtocolPAA11Distributed01_F9ActorStubRzrlE5greetSSyYaKFTE`
which is an extension method: `distributed thunk (extension in main):main.GreeterDefinedSystemProtocol< where A: Distributed._DistributedActorStub>.greet() async throws -> Swift.String`,
this very specific design allows us to call the "right method" on the
recieving end of a remote call where we do not know the recipient type.
This type is intended to be used to wrap compiler synthesized nodes
(i.e. variables) to make it easier for diagnostic to diagnose precise
failure locations.
Consider the situation like:
```
protocol P {}
extension Array: P where Element: P {}
func test<T: P>() -> T {
$_a = ...
$_b = ...
return [$_a, $_b]
}
```
This is a common pattern with result builders.
In this case if one of the elements don't conform to `P` the best
user experience would be to attach diagnostic to the element otherwise
the developers would have to figure out where in result expression
the error occured before attempting to fix it.
Previously, they were being parsed as top-level code, which would cause
errors because there are no definitions. Introduce a new
GeneratedSourceInfo kind to mark the purpose of these buffers so the
parser can handle them appropriately.
This was never implemented properly, but it works sometimes.
When the protocol is parameterized, it started crashing in a new way,
because the interface type of an existential is now derived from the
generalization signature, which will have nothing to do with the
signature that IRGen is passing in here.
Tweak the workaround to keep things limping along.
Fixes rdar://problem/139745699
I added commit 7eecf97132 a while ago
to fix a newly-added assertion failure that came up, however this
had the inadvertent side effect of changing symbol mangling and
ASTPrinter behavior.
The problem in both instances was that we would incorrectly return
certain requirements as unsatisfied when really they are satisfied.
There is nothing to fix in the ASTPrinter, because printing redundant
requirements does not change the generic signature of the extension;
they are simply dropped. I added a test to exercise the new behavior
showing that the requirements are dropped.
As for the mangler, the fix introduced an ABI break, because the
symbol name of a conformance descriptor includes its conditional
requirements, so we must preserve the redundant requirements forever.
The IRGen test has some examples of manglings that are incorrect but
must be preserved.
I'm plumbing down a flag to isRequirementSatified() to preserve
compatibility with the old behavior where we would mangle these
redundant requirements. No other callers should pass this flag,
except for the mangler.
Fixes rdar://139089004.
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.
`Builtin.FixedArray<let N: Int, T: ~Copyable & ~Escapable>` has the layout of `N` elements of type `T` laid out
sequentially in memory (with the tail padding of every element occupied by the array). This provides a primitive
on which the standard library `Vector` type can be built.
The main change here is to associate a witness table with a `ProtocolConformance` instead of a `RootProtocolConformance`.
A `ProtocolConformance` is the base class and can be a `RootProtocolConformance` or a `SpecializedProtocolConformance`.
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.
