Printing Doxygen isn't inside an XML tag, so we can't just print
code block content, which may have new lines without a doc comment
marker. Also, be more robust with indentation.
+ Tests.
rdar://problem/20703026
Swift SVN r27851
Replace ReST-flavored documentation comments with Markdown.
rdar://problem/20180412
In addition to full Markdown support, the following extensions are
supported. These appear as lists at the top level of the comment's
"document". All of these extensions are matched without regard to
case.
Parameter Outlines
------------------
- Parameters:
- x: ...
- y: ...
Separate Parameters
-------------------
- parameter x: ...
- parameter y: ...
- Note:
Parameter documentation may be broken up across the entire comment,
with a mix of parameter documentation kinds - they'll be consolidated
in the end.
Returns
-------
- returns: ...
The following extensions are also list items at the top level, which
will also appear in Xcode QuickHelp as first-class citizens:
- Attention: ...
- Author: ...
- Authors: ...
- Bug: ...
- Complexity: ...
- Copyright: ...
- Date: ...
- Experiment: ...
- Important: ...
- Invariant: ...
- Note: ...
- Postcondition: ...
- Precondition: ...
- Remark: ...
- Remarks: ...
- See: ...
- Since: ...
- Todo: ...
- Version: ...
- Warning: ...
These match most of the extra fields in Doxygen, plus a few more per request.
Other changes
-------------
- Remove use of rawHTML for all markup AST nodes except for those
not representable by the Xcode QuickHelp XSLT - <h>, <hr/>, and of
course inline/block HTML itself.
- Update the doc comment RNG schema to more accurately reflect Xcode
QuickHelp.
- Clean up cmark CMake configuration.
- Rename "FullComment" to "DocComment"
- Update the Swift Standard Documentation (in a follow-up commit)
- Update SourceKit for minor changes and link against cmark
(in a follow-up commit).
Swift SVN r27727
Refactor the Objective-C selector computation code for all forms of
methods, collapsing it into a single routine to eliminate
duplication. Test that we're computing Objective-C selectors for
throwing initializers correctly, as well as that we're printing the
appropriate Objective-C method declarations for throwing
initializers.
Swift SVN r27293
When printing the Objective-C form of a throwing method, use the
appropriate result type (BOOL, nullable result, etc.) and include the
error parameter. As part of this, refactor the printing loop for
Objective-C method declarations to stop being based on splitting
strings: ObjCSelector has the pieces we need.
Swift SVN r27282
This only affects configurations where the overlays are built separately.
We should revisit our pile of hacks at some point.
rdar://problem/20474561
Swift SVN r27148
Another step toward using the conformance lookup table for
everything. This uncovered a tricky little bug in the conformance
lookup table's filtering logic (when asking for only those
conformances explicitly specified within a particular context) that
would end up dropping non-explicit conformances from the table (rather
than just the result).
Ween a few tests off of -enable-source-import, because they'll break
otherwise.
Swift SVN r27021
Swift's bridged collections are allowed to store objects of non-@objc
classes, e.g., an array of (non-@objc) Swift classes is still bridged
to NSArray. Deal with such cases by printing out the type as "NSArray
*", since we cannot name the type in Objective-C to provide a more
specialized NSArray type.
This is a fairly narrow fix for rdar://problem/20392771 that needs
more discussion.
Swift SVN r26905
(Note that this registry isn't fully enabled yet; it's built so that
we can test it, but has not yet taken over the primary task of
managing conformances from the existing system).
The conformance registry tracks all of the protocols to which a
particular nominal type conforms, including those for which
conformance was explicitly specified, implied by other explicit
conformances, inherited from a superclass, or synthesized by the
implementation.
The conformance registry is a lazily-built data structure designed for
multi-file support (which has been a problematic area for protocol
conformances). It allows one to query for the conformances of a type
to a particular protocol, enumerate all protocols to which a type
conforms, and enumerate all of the conformances that are associated
with a particular declaration context (important to eliminate
duplicated witness tables).
The conformance registry diagnoses conflicts and ambiguities among
different conformances of the same type to the same protocol. There
are three common cases where we'll see a diagnostic:
1) Redundant explicit conformance of a type to a protocol:
protocol P { }
struct X : P { }
extension X : P { } // error: redundant explicit conformance
2) Explicit conformance to a protocol that collides with an inherited
conformance:
protocol P { }
class Super : P { }
class Sub : Super, P { } // error: redundant explicit conformance
3) Ambiguous placement of an implied conformance:
protocol P1 { }
protocol P2 : P1 { }
protocol P3 : P1 { }
struct Y { }
extension Y : P2 { }
extension Y : P3 { } // error: ambiguous implied conformance to 'P1'
This happens when two different explicit conformances (here, P2 and
P3) placed on different declarations (e.g., two extensions, or the
original definition and other extension) both imply the same
conformance (P1), and neither of the explicit conformances imply
each other. We require the user to explicitly specify the ambiguous
conformance to break the ambiguity and associate the witness table
with a specific context.
Swift SVN r26067
This is required to correctly use the mock SDK when the SDK overlay is
built and tested separately. (Otherwise, the mock SDK might not get
used, because the overlay SDK options would expand from the
%-substitution, appear first on the command line, and shadow the mock
SDK in the search path).
Swift SVN r25185
Only create trivial accessors if the actual VarDecl is @objc,
explicitly or implicitly, not the class.
Also, replicate the PrintAsObjC test into classes_objc_generics since
"classes" isn't run on compilers that support Objective-C generics, and
fix the expectations.
Swift SVN r25162
That's a C11 feature, and we can't force everyone to enable C11 just yet.
Instead, go back to the old way of using "enum Foo" to refer to @objc enums
defined in Swift. Just don't do it unilaterally for non-@objc enums.
Should unstick the buildbot.
Swift SVN r25161
Expose static stored properties in @objc classes as trivial class
methods.
static let i: T => +(T)i
static var i: T => +(T)i and +(void)setI:
static var k T { get set } => No change.
Fixes rdar://problem/19784053
Swift SVN r25152
For pointer types that Swift doesn't currently import using Optional
(see rdar://problem/15189170 and its dups), use __null_unspecified.
rdar://problem/19775335
Swift SVN r25144
...and then fix our forward-declaration logic that assumed that they did.
This fixes a rare case where we would end up printing "enum" twice if the
user (benignly) misused NS_ENUM.
rdar://problem/19769964
Swift SVN r25143
If a property, method, or subscript overrides an imported property, method,
or subscript that was originally declared using NSUInteger as a property,
parameter, or return type, print the subclass's member using "NSUInteger"
in the generated header to prevent override warnings.
This doesn't handle all cases--in particular, it doesn't handle the
NSUInteger being nested inside a larger type--but it does get the easy
ones correct. I think the easiest way to be more correct would be to mark
NSUInteger-as-Int somehow using a distinct type. (Hidden attribute?
Another typealias? Not sure.)
rdar://problem/19321126
Swift SVN r24771
Previously, when dealing with CF typedefs of other CF types, we would strip
off the "Ref" suffix...and then leave it off when it came time to print the
Objective-C header.
rdar://problem/19446942
Swift SVN r24562
PrintAsObjC behaves slightly differently in apps vs. frameworks: for apps,
you get internal decls exposed in the header as well as public ones. This
is because the generated header is not being shipped anywhere and thus we
don't have a secrecy leak.
However, we were detecting whether we were in an app based on whether or
not we had a bridging header. That's no good for mixed-source apps where
there's no bridging header, so now we also check for a main entry point,
whether generated from @UIApplicationMain or @NSApplicationMain, or from
a script source file (main.swift).
rdar://problem/17877235
Swift SVN r24532
Most tests were using %swift or similar substitutions, which did not
include the target triple and SDK. The driver was defaulting to the
host OS. Thus, we could not run the tests when the standard library was
not built for OS X.
Swift SVN r24504
rdar://problem/17198298
- Allow 'static' in protocol property and func requirements, but not 'class'.
- Allow 'static' methods in classes - they are 'class final'.
- Only allow 'class' methods in classes (or extensions of classes)
- Remove now unneeded diagnostics related to finding 'static' in previously banned places.
- Update relevant diagnostics to make the new rules clear.
Swift SVN r24260
Rely on Foundation to provide NS_ARRAY/NS_DICTIONARY/NS_SET macros
that expand to either an unspecialized type (e.g., NSArray *) or a
specialized one (e.g., NSArray<T> *) as appropriate for the definition
of NSArray. Use these macros in the Objective-C printer.
The actual names and form of these macros is still to be debated, but
it's important to be able to handle both Clangs and Foundations with
and without parameterized NSArray/NSDictionary/NSSet.
Swift SVN r24198
Doing so is safe even though we have mock SDK. The include paths for
modules with the same name in the real and mock SDKs are different, and
the module files will be distinct (because they will have a different
hash).
This reduces test runtime on OS X by 30% and brings it under a minute on
a 16-core machine.
This also uncovered some problems with some tests -- even when run for
iOS configurations, some tests would still run with macosx triple. I
fixed the tests where I noticed this issue.
rdar://problem/19125022
Swift SVN r23683
If enums are used as parameters or returns of @objc methods, we may need to forward declare those enums when printing the class @interface.
Swift SVN r23445
This is necessary for @objc enums because, for C compatibility, the representations of the cases must match their raw values. We might want to do this for sufficiently fragile Swift enums in the future too, but that can wait. This lets us successfully print the raw values as ObjC.
Swift SVN r23423
Predefine a SWIFT_ENUM macro that expands the same as NS_ENUM, but which we can use to recognize Swift-defined @objc enums that are imported back. Print enums as ObjC using this SWIFT_ENUM macro.
We currently don't serialize the raw value exprs of enums, so we fail to correctly bring raw values from the enum declaration to the ObjC version.
Swift SVN r23422
