Otherwise, we cram a conventionally UpperCamelCase thing with a
newly-conventinally-lowerCamelCased thing together and destroy the
word boundaries. Fixes rdar://problem/24947695.
Including the argument names helps code completion in Xcode.
Fixes SR-365.
Also fixes an issue where a property of a block/function type whose name
is a clang keyword would produce an invalid declaration, e.g.
var `struct`: (Int -> Int)?
was printing as
@property (nonatomic, copy, getter=struct, setter=setStruct:) NSInteger (^ _Nullable struct)(NSInteger)_;
The Objective-C Cocoa convention eschew "is" on property names, but
use it on the getter, while the Swift API guidelines state that
Boolean properties should read as assertions (e.g., "isEmpty" rather
than "empty"). Map Swift properties named "isFoo" to Objective-C by
removing the "is" from the resulting Objective-C property name (so it
will be named "foo") and from the setter (which will have the
Objective-C selector "setFoo:") while retaining the "is" for the
getter selector ("isFoo").
Fixes rdar://problem/17090661.
Also make sure the `FooDomain` constant for `ErrorType` enums uses the
correct name.
Fixes SR-693: Custom named @objc enum still exposes original Swift name
in Objective-C
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
