Bridge types during import only if we are in a fully-bridgeable context. #10832
Conversation
|
@swift-ci Please test. |
|
Build failed |
rjmccall
force-pushed
the
fix-function-component-bridging-import
branch
from
db4cef2 to
37e7c7b
Compare
|
@swift-ci Please test. |
|
Build failed |
|
Build failed |
Somehow the logic had slipped so that we were basing this decision purely on the ImportTypeKind and not on whether the broader context is bridgeable. This was allowing us to use bridged types when e.g. importing the results and parameters of C function pointer types, which is really bad. Also, when importing a reference to a typedef of block type, do not use the typedef in a non-bridgeable context. We import typedefs of block type as fully-bridged types, but this means that it is invalid to import a type using the typedef in a context where the original C type must be used. Similarly, make sure we use a properly-imported underlying type of the typedef when the typedef itself is unavailable. Also, extend the special behavior of block typedefs to abstract-function typedefs, which seems to be consistent with the expected behavior of the tests. Finally, I changed importType to take a new Bridgeability enum instead of a raw canFullyBridgeTypes bool. At the time, I was doing that because I was going to make it tri-valued; that turned out to be unnecessary, but I think it's an improvement anyway.
rjmccall
force-pushed
the
fix-function-component-bridging-import
branch
from
37e7c7b to
0e89efa
Compare
|
@swift-ci Please test. |
|
Build failed |
|
Build failed |
|
Hm, I wonder if this fixed rdar://problem/33027057. |
|
So it looks like this caused rdar://problem/34913634, because block-typed globals aren't bridged anymore. I tried to just re-enable that by checking for blocks in cc @slavapestov |
|
I think the original change might have gone the wrong way entirely, actually. We implicitly un-bridge all the component types of C/block function types in SILGen, which I didn't realize, so arguably we ought to bridge all the component types of function types during import regardless of the context. |
|
I ran into trouble with that too. I'll check it again tomorrow. |
|
I suspect that I fixed rdar://problem/34913634 with #12680, because it reinstated bridging for typedefs. |
Somehow the logic had slipped so that we were basing this decision purely
on the ImportTypeKind and not on whether the broader context is bridgeable.
This was allowing us to use bridged types when e.g. importing the results and
parameters of C function pointer types, which is really bad.
Also, when importing a reference to a typedef of block type, do not use
the typedef in a non-bridgeable context. We import typedefs of block type
as fully-bridged types, but this means that it is invalid to import a type
using the typedef in a context where the original C type must be used.
Similarly, make sure we use a properly-imported underlying type of the
typedef when the typedef itself is unavailable.
Also, extend the special behavior of block typedefs to abstract-function
typedefs, which seems to be consistent with the expected behavior of the
tests.
Finally, I changed importType to take a new Bridgeability enum instead of
a raw canFullyBridgeTypes bool. At the time, I was doing that because I
was going to make it tri-valued; that turned out to be unnecessary, but I
think it's an improvement anyway.