...and just outright import the bridging header if that's what's needed.
This means we'll use @class and @protocol whenever we're just using a class
or protocol in a type, but still import the enclosing module when we need
the definition. We'll also fall back to the module (or bridging header) if
we need something /else/ from C: a struct, a typedef, whatever.
<rdar://problem/17183425>
Swift SVN r18795
When generating a header for the Swift half of a mixed-source framework,
we can't import the framework using @import, because that means a submodule
is trying to import a parent module before the module is done being built.
This currently isn't supported in Clang, though it only recently became an
error instead of being ignored.
Instead, we now assume that the framework will have an umbrella header with
the same name as the framework module, which is the same assumption Xcode
makes when you don't provide your own module map. I'm not too concerned about
people trying to build mixed-source frameworks who /don't/ have umbrella
headers.
This doesn't affect app targets at all, which use -import-objc-header instead
of a standalone underlying module.
<rdar://problem/16879704>
Swift SVN r17984
