Implement Swift serialization and deserialization of Clang types #29670
Conversation
|
@swift-ci Please test. |
|
Build failed |
|
Could you elaborate on this with an example:
Are bridging headers special because they are not part of a module (I think?)? Also, it feels like this knowledge of exceptional cases should be documented somewhere alongside the code itself, but I'm not entirely sure where. |
|
Can you add a couple of test cases with
[I don't think that requires SIL work to land, does it?] |
Right, in two different ways. They're not part of a module, so we have no way of figuring out where they're from; and that's supposed to be okay because you aren't supposed to use declarations from bridging headers in module interfaces, which is currently enforced by simply not allowing modules to have bridging headers except for the final executable (which then doesn't have an interface). The general restriction should be enforced in the type-checker, and we want to do that as part of the implementation-only imports checking, but we haven't yet. I suspect it will look a lot like this check. |
rjmccall
force-pushed
the
ciliainig-teyepee-sieeriiieaileiizieaitieieoiniie
branch
from
54e9dce to
a242ae3
Compare
|
@swift-ci Please test |
I'll flesh out the serialization tests some more tomorrow. It shouldn't need SIL work. |
|
Build failed |
|
Build failed |
rjmccall
force-pushed
the
ciliainig-teyepee-sieeriiieaileiizieaitieieoiniie
branch
from
a242ae3 to
f344d0a
Compare
|
@swift-ci Please test |
|
@swift-ci Please test source compatibility |
|
Build failed |
|
Build failed |
rjmccall
force-pushed
the
ciliainig-teyepee-sieeriiieaileiizieaitieieoiniie
branch
from
f344d0a to
cf8be9e
Compare
|
@swift-ci Please test. |
|
Build failed |
|
Build failed |
|
@swift-ci Please test OS X |
|
I've mostly looked at everything except |
As part of this, we have to change the type export rules to prevent `@convention(c)` function types from being used in exported interfaces if they aren't serializable. This is a more conservative version of the original rule I had, which was to import such function-pointer types as opaque pointers. That rule would've completely prevented importing function-pointer types defined in bridging headers and so simply doesn't work, so we're left trying to catch the unsupportable cases retroactively. This has the unfortunate consequence that we can't necessarily serialize the internal state of the compiler, but that was already true due to normal type uses of aggregate types from bridging headers; if we can teach the compiler to reliably serialize such types, we should be able to use the same mechanisms for function types. This PR doesn't flip the switch to use Clang function types by default, so many of the clang-function-type-serialization FIXMEs are still in place.
rjmccall
force-pushed
the
ciliainig-teyepee-sieeriiieaileiizieaitieieoiniie
branch
from
cf8be9e to
faee21b
Compare
|
@swift-ci Please smoke test |
|
@swift-ci Please smoke test OS X |
I'm going to merge, but if you have further suggestions, I'd be happy to apply them in a follow-up. |
rjmccall
deleted the
ciliainig-teyepee-sieeriiieaileiizieaitieieoiniie
branch
As part of this, we have to change the type export rules to prevent
@convention(c)function types from being used in exported interfaces if they aren't serializable. This is a more conservative version of the original rule I had, which was to import such function-pointer types as opaque pointers. That rule would've completely prevented importing function-pointer types defined in bridging headers and so simply doesn't work, so we're left trying to catch the unsupportable cases retroactively. This has the unfortunate consequence that we can't necessarily serialize the internal state of the compiler, but that was already true due to normal type uses of aggregate types from bridging headers; if we can teach the compiler to reliably serialize such types, we should be able to use the same mechanisms for function types.This PR doesn't flip the switch to use Clang function types by default, so many of the clang-function-type-serialization FIXMEs are still in place.