RemoteMirror generic multi-payload-enum fixes #41903
Conversation
Apparently, RemoteMirror chokes on certain MPEs with generic payload types. It does not recognize the generic payload type so ends up defaulting to a zero size. This causes the overall enum size to be miscalculated unless there is another non-generic payload that's at least as large. Step 1: Test case
|
First step: Test case. |
|
@swift-ci Please test |
|
✅Test fails. |
|
The underlying issue seems to be that when you have a generic multi-payload enum inside a generic class, we need to resolve a generic type parameter with depth "1". That in turn requires that the layout computations for the enum be able to follow the |
This particular case requires us to reprocess the metatype to "thicken" it.
That process inadvertently lost information about the depth of generic
nesting, which caused the RemoteMirror to be unable to resolve the type of
`C.E.t` at runtime.
```
class C<T> {
enum E<T> {
case t(T)
case u(Int)
}
var e: E<T>?
}
```
This adds code to the thickening logic to preserve parent-type
information, which allows us to properly handle nested generic
types of this sort.
Resolves rdar://90490128
|
Thanks to @slavapestov for pointing me to the right fix for this. The "metatype thickening" logic was inadvertently dropping information about the surrounding generic type when you had nested generics. The solution was to recursively thicken the parent in this case. |
|
@swift-ci Please test |
|
Most recent tests passed everywhere except on 32-bit (expected because the sizes are different there). I fixed up the test accordingly and it should pass now. |
|
@swift-ci Please test |
Apparently, RemoteMirror chokes on certain MPEs with generic payload types.
It does not recognize the generic payload type so ends up defaulting to a
zero size. This causes the overall enum size to be miscalculated unless there
is another non-generic payload that's at least as large.
Resolves rdar://90490128