Lift the decision of whether a method needs a vtable slot up to AST. #9309
Conversation
|
Note: In the long-term, we'd probably prefer to just consider SIL vtables the canonical layout for a vtable. But we don't think SIL serialization is in a good enough state to use for arbitrary code in Swift 4. |
This allows fuzzy matching of top-level optionals in types, using the same logic we use to fuzzy-match potential overrides.
The previous logic accidentally propagated the "is parameter" flag into any number of nested tuples. Fix this by differentiating between "input of a function type" and "member of a tuple that's the input of a function type".
It's doing essentially the same walk, just with different rules at each step. This is also something we want accessible at the AST level (see subsequent commits).
This lets us serialize that decision, which means we can conceivably /change/ the decision in later versions of the compiler without breaking existing code. More immediately, it's groundwork that will eventually allow us to drop decls from the AST without affecting vtable layout. This isn't actually a great answer; what we really want is for SIL vtables to be serialized consistently and treated as the point of truth. But that would be more change than we're comfortable taking in the Swift 4 timeframe. First part of rdar://problem/31878396.
|
@swift-ci Please test |
|
Build failed |
|
Build failed |
|
Thanks! Even once we serialized SIL vtable a we still need to do something about classes in multi-file modules. Lifting this up to the AST makes sense to me regardless, since it's in terms of AST types. |
|
I'm not sure how this helps the cross-file case. It seems like you still have to do the same amount of work in both cases? |
|
Right, I just meant that we can't always rely on the SIL vtable even in the future when SIL serialization always works |
Lift the decision of whether a method needs a vtable slot up to AST.
This lets us serialize that decision, which means we can conceivably change the decision in later versions of the compiler without breaking existing code. More immediately, it's groundwork that will eventually allow us to drop decls from the AST without affecting vtable layout.
First half of <rdar://problem/31878396> Deserialization: Dropping members from a class affects the layout of its vtable