This change adds infrastructure to represent inline markup in the AST,
implements parsing of some of the inline markup (*emphasis*, **strong
emphasis**, `interpreted text`, ``inline literal``), and XML generation
for these constructs for SourceKit clients to consume.
The parsing itself is incomplete for constructs not mentioned above.
Most notably, we don't parse hyperlinks, and we don't parse the
double-colon that changes the next paragraph into a literal block.
Swift SVN r22752
ownership attributes by bracketting
header with specific group warning pragma clang.
This patch also requires patch for rdar://17845264
which is currently in TOT. This is //rdar://17023083
Swift SVN r20767
...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
Also, use "#include <objc/NSObject.h>" instead of "@import ObjectiveC;"
to get access to BOOL, SEL, NSObject, and NSString.
This allows generated headers to be used in Objective-C++ contexts, where
modules don't yet work. The dependencies will unfortunately need to be
imported separately (because there's not a direct mapping from module name
back to header file), but that's still better than just being incompatible.
<rdar://problem/16796627>
Swift SVN r17272
of better markup in current XML schema
I know this XML is probably as bad as XML can get, but at least it allows
clients to render some block markup. I expect to replace this with some real
tags soon.
Swift SVN r16657
This commit adds infrastructure for conversion and testing it.
The conversion is still incomplete, pending discussion about which tags should
we use in the XML documents. I copied the RelaxNG schema from Clang, and will
edit it accordingly.
Swift SVN r16451
The actual logic to do this is simple; the vast majority of this
commit is just a pile of changes to test cases to reflect the fact
that Objective-C metadata now includes the module name for each class
and the mangling of Swift-defined @objc classes no longer goes into
the "So" namespace for Objective-C classes. Finishes
<rdar://problem/15506580>.
Swift SVN r16274
This makes sure that Clang uses the mangled class names for
Swift-defined classes. Should be last compiler-side piece of
<rdar://problem/15506580>.
Swift SVN r15977
The results don't look that great in the header file code when we fall back to
HTML, but there is no other option. We could try to pretty-print HTML at best.
Swift SVN r15874
This means more duplication, but it's also more future-proof: the set of
features used is based on the compiler that generates the header, not the
compiler that eventually consumes the header. To allow for forward-
compatibility, all the macros used by the header can be overridden by the
consuming environment, and the header <swift/objc-prologue.h> will be
included if it exists.
Swift SVN r14893
