Add a new convention to describe what happens with
nonzero_result on a type that isn't imported as Bool.
This isn't really a safe convention to implement, but
calls are fine.
Implements <rdar://21715350>.
Swift SVN r29953
This is half of rdar://problem/17469485. The other half will be
recognizing in the importer that the Objective-C declaration references
a Swift type; see next commit.
Swift SVN r29743
This very simply avoids printing properties and method arguments whose
names match /any/ keyword recognized by Clang, in any language mode.
That's a bit overkill, but it's easiest to implement. If someone /does/
name their property or argument using a keyword, a single underscore is
appended. That's suboptimal for properties, but better than the "header
fails to parse" alternative.
If you've named your /type/ something that conflicts with C, you deserve
what you get. Mark the thing @nonobjc. (We could actually check this in
Sema, but it's rare enough that I'm going to punt on doing that for now.)
rdar://problem/21060399
Swift SVN r29473
We were printing getter/setter names when the property came from
Objective-C initially, which is incorrect: we should print them when
the names differ from what Objective-C would compute by default. This
finishes rdar://problem/19408726, which was mostly in place a while
ago.
Swift SVN r28783
This is NFC, because we were already properly using
getObjCPropertyName() for the general case. Only the
imported-from-an-NSUInteger property case remained, which will
currently have getName() == getObjCPropertyName(). But, be consistent
to be more future-proof, if renaming of @properties should come.
Swift SVN r28782
The macro hackery here was staging while we waited for Foundation's
parameterized collections to percolate through the system, then I
forgot about it. Eliminate the hackery so the Objective-C view of
Swift APIs actually produces specialized types such as
NSArray<NSString *> *.
Be a bit more careful when printing parameterized Foundation
collections, to ensure that we only print the type arguments if
they're guaranteed to be printed as object types.
Fixes rdar://problem/20984336.
Swift SVN r28677
We just use a static string constant for now, which isn't at all resilient.
But it works! Credit to JoeG for coming up with this solution.
Part of rdar://problem/20577517
Swift SVN r28662
The macro hackery here was staging while we waited for Foundation's
parameterized collections to percolate through the system, then I
forgot about it. Eliminate the hackery so the Objective-C view of
Swift APIs actually produces specialized types such as
NSArray<NSString *> *.
Fixes rdar://problem/20984336.
Swift SVN r28650
Reverts r28087. We're going back to the C++ interface for SIMD, and the changes in this patch are needless complication for that design.
Swift SVN r28384
Modules occupy a weird space in the AST now: they can be treated like
types (Swift.Int), which is captured by ModuleType. They can be
treated like values for disambiguation (Swift.print), which is
captured by ModuleExpr. And we jump through hoops in various places to
store "either a module or a decl".
Start cleaning this up by transforming Module into ModuleDecl, a
TypeDecl that's implicitly created to describe a module. Subsequent
changes will start folding away the special cases (ModuleExpr ->
DeclRefExpr, name lookup results stop having a separate Module case,
etc.).
Note that the Module -> ModuleDecl typedef is there to limit the
changes needed. Much of this patch is actually dealing with the fact
that Module used to have Ctx and Name public members that now need to
be accessed via getASTContext() and getName(), respectively.
Swift SVN r28284
The design we landed on for SIMD is to define the vector types as nested types of their element, e.g. Float.Vector4, Int32.Vector2, etc. Update the Clang importer and other mapping facilities to match.
Swift SVN r28087
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
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
These aren't really orthogonal concerns--you'll never have a @thick @cc(objc_method), or an @objc_block @cc(witness_method)--and we have gross decision trees all over the codebase that try to hopscotch between the subset of combinations that make sense. Stop the madness by eliminating AbstractCC and folding its states into SILFunctionTypeRepresentation. This cleans up a ton of code across the compiler.
I couldn't quite eliminate AbstractCC's information from AST function types, since SIL type lowering transiently created AnyFunctionTypes with AbstractCCs set, even though these never occur at the source level. To accommodate type lowering, allow AnyFunctionType::ExtInfo to carry a SILFunctionTypeRepresentation, and arrange for the overlapping representations to share raw values.
In order to avoid disturbing test output, AST and SILFunctionTypes are still printed and parsed using the existing @thin/@thick/@objc_block and @cc() attributes, which is kind of gross, but lets me stage in the real source-breaking change separately.
Swift SVN r27095
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
Previously some parts of the compiler referred to them as "fields",
and most referred to them as "elements". Use the more generic 'elements'
nomenclature because that's what we refer to other things in the compiler
(e.g. the elements of a bracestmt).
At the same time, make the API better by providing "getElement" consistently
and using it, instead of getElements()[i].
NFC.
Swift SVN r26894
Currently a no-op, but effective access for entities within the current
module will soon need to take testability into account. This declaration:
internal func foo() {}
has a formal access of 'internal', but an effective access of 'public' if
we're in a testable mode.
Part of rdar://problem/17732115 (testability)
Swift SVN r26472
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
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
Curried function parameters (i.e., those past the first written
parameter list) default to having argument labels (which they always
have), but any attempt to change or remove the argument labels would
fail. Use the fact that we keep both the argument labels and the
parameter names in patterns to generalize our handling of argument
labels to address this problem.
The IDE changes are due to some positive fallout from this change: we
were using the body parameters as labels in code completions for
subscript operations, which was annoying and wrong.
Fixes rdar://problem/17237268.
Swift SVN r24525
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
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
