The swift_name string format now supports "getter:" and "setter:"
prefixes to indicate that a function is the getter or setter of a
Swift-synthesized property. Start parsing these DeclNames and make
sure they're reflected in the Swift name lookup tables.
[Clang update required]
A swift_name attribute on a global declaration can specify a dotted
name (e.g., SomeStruct.member) to map that global into a member of the
(Swift-)named type. Handle this mapping in DeclName parsing, plumb it
through importFullName, and cope with it in the Swift name lookup
tables (tested via the dump) and importing into a Swift DeclContext
(as-yet-untested). Part of SE-0033.
Previously, the "effective context" parameter to importFullName was
used only during the construction of Swift name lookup tables, so we
can associate each declaration with a context. Expand the role of
"effective context" so it is always a part of ImportedName and is also
used by importDecl when actually importing the enum declaration.
This is partially a cleanup, and partially staging for SE-0033, which
will require this functionality more broadly.
This reorganization allows adding attributes that refer to types.
I need this for a @_specialize attribute with a type list.
PrintOptions.h and other headers depend on these enums. But Attr.h
defines a lot of classes that almost never need to be included.
Introduce DarwinPlatformKind, which would allow us to switch on darwin
platforms instead of copying and pasting the brittle logic in several places.
Use the helper method to simplify ClangImporter.
Rather than managing API notes directly in the Clang importer, tell
Clang where to find the API notes files and let it map them directly
to attributes. Then, use the existing attribute-mapping
mechanisms---with minor extensions for cases where Clang previously
didn't map some Swift-specific API notes---to get at that information.
There is a minor regression where we can no longer apply API notes to
declarations that don't have a specific Clang declaration. The
specific example (NSError's inherited init()) comes from
rdar://problem/21042412; we've regressed here, but the correct fix is
(and has always been) on the Objective-C side
(rdar://problem/19977891).
Finishes rdar://problem/24447420.
When we transform an Objective-C method or property name, we take into
account the parameter types, result type, and type of the enclosing
context. Doing so means that one can get different Swift names for a
particular method (or property) and one that overrides it, which leads
to dangerous inconsistencies in the Swift names. Address this
limitation by using the original declaration's name (i.e., one that
does not override any other).
It is possible that there is more than one "original declaration",
when the same method/property name comes from different
protocols. When this is the case, check for consistency and complain
if there are inconsistencies.
Amusingly, this changes exactly one method in Cocoa
(UINavigationController's showViewController:sender:), with no conflicts
detected. Fixes rdar://problem/24558337.
Introduces new class, EnumInfo, just for the implementation of the
ClangImporter to encapsulate various computed information about the
enum we're importing.
This helps refactor some functionality, aids clarity, and also
prevents us from repeating calculations multiple times, as we were
doing with classifyEnum's macro-expansion tracking. Provides a base
where we can add more heavy lifting in classifyEnum in the future.
Clean up our handling of the removal of the "NS" prefix from
Foundation-defined entities in a few ways:
* If the "NS" is followed by a "_", strip that too
* Make sure that the result is still an identifier ("NS123" shouldn't
become "123"!)
* Don't lowercase ALL_CAPS_NAMES
CF types are generally imported twice, once with the "Ref" and once
without the "Ref", unless the non-"Ref" version would conflict with
some other declaration (e.g., an Objective-C class of the same name).
The logic to create both versions was a bit convoluted, and tended to
return the "Ref" version as the primary declaration, which conflicts
with our general inclination to use the non-"Ref" version. Now we create
the non-"Ref" version directly and then create the aliased "Ref" version
as an alternate declaration. The "Ref" version is a typealias of the
non-"Ref" version, and the "Ref" version is never used anywhere else
in the AST.
Also, improve the conflict resolution for cases where the only
conflicting declaration is an opaque tag used to declare the CF type
itself, e.g.,
typedef struct CGImage *CGImageRef;
These cases used to be considered conflicts, but they are benign
because the underlying struct will never actually be imported. Make
them not conflicts, so we get the preferred name "CGImage" rather than
"CGImageRef".
Introduce Fix-Its to aid migration from selectors spelled as string
literals ("foo:bar:", which is deprecated), as well as from
construction of Selector instances from string literals
(Selector("foo:bar"), which is still acceptable but not recommended),
to the #selector syntax. Jump through some hoops to disambiguate
method references if there are overloads:
fixits.swift:51:7: warning: use of string literal for Objective-C
selectors is deprecated; use '#selector' instead
_ = "overloadedWithInt:" as Selector
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#selector(Bar.overloaded(_:) as (Bar) -> (Int) -> ())
In the cases where we cannot provide a Fix-It to a #selector
expression, we wrap the string literal in a Selector(...) construction
to suppress the deprecation warning. These are also easily searchable
in the code base.
This also means we're doing more validation of the string literals
that go into Selector, i.e., that they are well-formed selectors and
that we know about some method that is @objc and has that
selector. We'll warn if either is untrue.
As part of the improved import of Objective-C APIs into Swift, strip
the "NS" prefix from entities defined in the Foundation
framework. Addresses rdar://problem/24050011, which is part of
SE-0005. Naturally, this is hidden behind -enable-omit-needless-words.
The Clang importer implementation held on to a Clang instance, which
held a list of module file extensions, which included the Clang
importer implementation... break the cycle by separating out the
module file extension from the Clang importer. Fixes SR-562 /
rdar://problem/24225173.
As part of the improved import of Objective-C APIs into Swift, strip
the "NS" prefix from entities defined in the Foundation
framework. Addresses rdar://problem/24050011, which is part of
SE-0005. Naturally, this is hidden behind -enable-omit-needless-words.
importFullName was inconsistent in the kinds of names it produced for
imported C functions. swift_name'd functions would get argument
labels, but non-swift_name'd functions would not, and other parts of
the important were working around the oddity. Make importFullName()
always provide the argument labels.
Introduce a new attribute, swift3_migration, that lets us describe the
transformation required to map a Swift 2.x API into its Swift 3
equivalent. The only transformation understood now is "renamed" (to
some other declaration name), but there's a message field where we can
record information about other changes. The attribute can grow
somewhat (e.g., to represent parameter reordering) as we need it.
Right now, we do nothing but store and validate this attribute.
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.
Enum constants are naturally going to be named after their ObjC name,
not their Swift name. As such, ignore the swift_name attr on the enum
decl when calculating the common prefix. It turns out this is actually
simpler anyway as it also bypasses the swift_private handling that the
code was already trying to work around.
The Swift name lookup tables and the complete Objective-C "container"
to Swift DeclContext mapping code used similar-but-different logic to
determine when to suppress a declaration (e.g., when suppressing the
accessors for a property). Centralize the logic so we get the same
behavior in both places.
Objective-C instance methods of root classes can also be used as class
methods, which we handle by performing a redundant import, the code
for which was scattered. Centralize this import as part of importing
the original (instance) method, and record it as an alternate
declaration to the original instance method. This eliminates a number
of special cases in the Clang importer.
Various interface-printing facilities use getTopLevelDecls to
enumerate the top-level declarations of a given module. For modules
imported from Clang, this walked a giant cached list of all
declarations known from Clang, then filtered out those that didn't
fit. Instead, just use the information provided by the Swift name
lookup tables, which is inherently module-specific and complete.
