Pitch: Improved ClangImporter Diagnostics

[zoecarver]

@allevato

Can we do better for incomplete types than just OpaquePointer or type-aliases of it? One of the most frustrating things about Swift's current C interop is that opaquifying (or vice-versa) C structs can be mostly non-source-breaking change in the C API, if the API vends pointers to the struct and the client doesn't access the fields directly, but when imported into Swift, pointers to the incomplete type are erased down to OpaquePointer . Swift clients have to update their code, and worse, all type safety is lost because pointers to different incomplete structs are indistinguishable. (Update BoringSSL to 25773430c07075a368416c3646fa4b07daf4968a by Lukasa · Pull Request #315 · apple/swift-nio-ssl · GitHub is a recent example of having to modify Swift code to account for this change in C.)

This is a really great idea. If I have time I'll try to put up a patch/post about this. It might be best to hide it behind an annotation, though, so we don't accidentally make it look like we can import types that we can't. (Though, with proper diagnostics, it might be OK because we could get an error like "cannot access fields of forward declared struct".) Maybe this fit's in with foreign reference types somehow...

@allevato

For Objective-C classes it may not be so easy, since the pointer to the class is imported as just a reference rather than an Unsafe(Mutable)Pointer . And there are probably many other edge cases I'm not considering here... but it would be great to move in that direction if we can.

IIRC we don't import pointers to forward declared Objective-C classes anyway :)