[docs] Tidy and document permissible conversions based on calling conventions #35457
Conversation
The existing polarity is sufficiently confusing that it has an explanatory comment at a return statement.
varungandhi-apple
changed the title
varungandhi-apple
requested review from
tbkka,
slavapestov and
xedin
and removed request for
slavapestov
| @@ -1590,6 +1590,10 @@ ManagedValue emitCFunctionPointer(SILGenFunction &SGF, | |||
| // C function pointers cannot capture anything from their context. | |||
| auto captures = SGF.SGM.Types.getLoweredLocalCaptures(constant); | |||
|
|
|||
| // Catch cases like: | |||
| // func g(_ : @convention(c) () -> ()) {} | |||
There was a problem hiding this comment.
I just want to say. Thank you so much for putting stuff like this in here! Very useful! = ).
lib/Sema/CSSimplify.cpp
Outdated
| /// The subtype relationship is defined as: | ||
| /// 1. any representation R is a sub-type of itself. | ||
| /// 2. a thin representation is a subtype of any other representation. | ||
| /// 3. a thick representation is a subtype of any other representation. |
There was a problem hiding this comment.
Is this true? Because thick-to-thin subtype is not allowed ... sorry, maybe I'm just a bit confused :)
There was a problem hiding this comment.
I think you are correct, at least that is how it was handled before, even examples still have passing a swift closure to @conversion(c) parameter as an error.
There was a problem hiding this comment.
Yeah, made a mistake there, it should be "a thick representation is a subtype of any other thick representation"
There was a problem hiding this comment.
Question, do you think would be informational note sub-type relation and variance here? As in (@convetion(c) () -> Void) -> Void sub (@convention(block) () -> Void) -> Void? I'm just wondering if this could be helpful in someway
There was a problem hiding this comment.
Function subtyping has multiple aspects: (1) representation/convention (2) variance (3) throws (4) @escaping. At the moment, this PR only documents (1), because that's the trickiest part.
The example you're describing falls out as a composition of (1) + (2). Are you suggesting that I document both (1) and (2) separately? Or is the suggestion that I specifically document that "(1) + (2) can be combined in such a way"?
There was a problem hiding this comment.
this PR only documents (1), because that's the trickiest part
Ah sure, better thinking about I agree it makes sense to only focus on (1) here
I just mentioned because (1) + (2) combined used to get me confused =]
lib/Sema/CSSimplify.cpp
Outdated
| /// The subtype relationship is defined as: | ||
| /// 1. any representation R is a sub-type of itself. | ||
| /// 2. a thin representation is a subtype of any other representation. | ||
| /// 3. a thick representation is a subtype of any other representation. |
There was a problem hiding this comment.
I think you are correct, at least that is how it was handled before, even examples still have passing a swift closure to @conversion(c) parameter as an error.
varungandhi-apple
force-pushed
the
vg-cleanup-rep-matching
branch
from
b4b9f84 to
29430d6
Compare
|
@swift-ci smoke test |
Fixes https://bugs.swift.org/browse/SR-14051 and matching rdar://73250604.
Also, I filed https://bugs.swift.org/browse/SR-14058 recently for the difference between the compiler and the runtime, so I figured it is worth updating
DynamicCasting.mdto reflect this.