SIL: Distinguish "compatible convention" and "compatible representation" function conversions. #28541
Conversation
…on" function conversions. We want to be able to use different representations for function types with otherwise compatible calling conventions. Distinguish these concepts in the `checkForABIDifferences` SIL APIs, so that we correctly handle representation-only conversions, which can be handled by `convert_function`, from full reabstractions, making sure to note that the representation-only case is not transitive for function arguments, since a function that takes a function with a representation change needs a thunk to change the argument's representation.
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
| // `SameCallingConvention`, then the outer function types may not themselves | ||
| // have the `SameCallingConvention` because they need a thunk to convert | ||
| // the inner function value representation. | ||
| CompatibleCallingConvention, |
There was a problem hiding this comment.
The contrast between this and the cases below isn't clear. Maybe something like:
The types have a representation difference that can be resolved with
convert_function, such as a possible difference in ptrauth discriminators.
We don't need to be coy about using ptrauth as an example.
The comment about nested positions applies to all these cases except CompatibleRepresentation, so maybe it should just go there.
Also you keep using SameCallingConvention in these comments, but it looks like you renamed that to CompatibleCallingConvention.
Longer-term question: should we just roll thin_to_thick_function into convert_function, so that we have one instruction for doing superficial conversions?
There was a problem hiding this comment.
Thanks, I'll clean up the comment in a follow up commit.
We want to be able to use different representations for function types with otherwise compatible
calling conventions. Distinguish these concepts in the
checkForABIDifferencesSIL APIs, so thatwe correctly handle representation-only conversions, which can be handled by
convert_function,from full reabstractions, making sure to note that the representation-only case is not transitive
for function arguments, since a function that takes a function with a representation change needs
a thunk to change the argument's representation.