Parameters (to methods, initializers, accessors, subscripts, etc) have always been represented
as Pattern's (of a particular sort), stemming from an early design direction that was abandoned.
Being built on top of patterns leads to patterns being overly complicated (e.g. tuple patterns
have to have varargs and default parameters) and make working on parameter lists complicated
and error prone. This might have been ok in 2015, but there is no way we can live like this in
2016.
Instead of using Patterns, carve out a new ParameterList and Parameter type to represent all the
parameter specific stuff. This simplifies many things and allows a lot of simplifications.
Unfortunately, I wasn't able to do this very incrementally, so this is a huge patch. The good
news is that it erases a ton of code, and the technical debt that went with it. Ignoring test
suite changes, we have:
77 files changed, 2359 insertions(+), 3221 deletions(-)
This patch also makes a bunch of wierd things dead, but I'll sweep those out in follow-on
patches.
Fixes <rdar://problem/22846558> No code completions in Foo( when Foo has error type
Fixes <rdar://problem/24026538> Slight regression in generated header, which I filed to go with 3a23d75.
Fixes an overloading bug involving default arguments and curried functions (see the diff to
Constraints/diagnostics.swift, which we now correctly accept).
Fixes cases where problems with parameters would get emitted multiple times, e.g. in the
test/Parse/subscripting.swift testcase.
The source range for ParamDecl now includes its type, which permutes some of the IDE / SourceModel tests
(for the better, I think).
Eliminates the bogus "type annotation missing in pattern" error message when a type isn't
specified for a parameter (see test/decl/func/functions.swift).
This now consistently parenthesizes argument lists in function types, which leads to many diffs in the
SILGen tests among others.
This does break the "sibling indentation" test in SourceKit/CodeFormat/indent-sibling.swift, and
I haven't been able to figure it out. Given that this is experimental functionality anyway,
I'm just XFAILing the test for now. i'll look at it separately from this mongo diff.
Use the keywords `_Nullable`, `_Nonnull`, and `_Null_unspecified`
instead of the older compatibility forms `__nullable`, `__nonnull`, and
`__null_unspecified`.
Part of rdar://problem/23614638
(And they are '__nonnull' rather than '_Nonnull' for two reasons:
it's a very cheap concession to preserve compatibility with Xcode 6.3,
and the existing code works this way.)
rdar://problem/22805286
Swift SVN r32228
We allow any array of bridgeable types to be converted to NSArray (and
similar for Dictionary and Set), but to be part of an API is a little
stricter. Previously, '[MySwiftObject]' as a parameter would get exposed
to Objective-C as 'NSArray *', but that's not type-safe at all---and in
corner cases, crashd in the ObjC printer. Now we just don't allow that.
On the plus side, '[Int]' is now exposed as 'NSArray<NSNumber *> *',
which is a fair amount better than just 'NSArray *'.
rdar://problem/19787270
Swift SVN r30719
These are contexts where we have enough information to bridge /back/
properly; that is, where we can distinguish CBool, ObjCBool, and
DarwinBoolean. In cases where we can't, we keep the three separate;
only CBool is really the same type as Bool.
This also affects current import behavior for ObjCBool, which was previously
incorrectly conflated with CBool in certain cases.
More rdar://problem/19013551
Swift SVN r30051
Like ObjCBool is a legitimate boolean type rather than a typealias for Int8,
DarwinBoolean is better than a typealias for UInt8. It's a BooleanType
(meaning you can use it directly in if/while/?:) and BooleanLiteralConvertible
(meaning you can use 'true' and 'false').
The next commit goes even further, so that you only have to deal with
DarwinBoolean when ABI is important. At all other times it should be
bridged with Bool, just like ObjCBool.
rdar://problem/19013551
Swift SVN r30050
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
