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.
This is the first in a series of patches that fixes some resilience-related
issues with synthesized accessors and materializeForSet.
Previously we maintained two lists of external declarations encountered while
type checking:
- ASTContext::ExternalDefinitions
- TypeChecker::implicitlyDefinedFunctions
The former contained the following:
- Imported nominal types from Clang, so that SILGen can emit witness tables
- Functions and variables with Clang decls, so that IRGen can instruct Clang
to emit them
- Synthesized accessors
The latter contained synthesized functions for derived conformances.
Since the second list was not visible outside Sema, we relied on the Clang
importer to add the type that contained the declaration to the
ExternalDefinitions list. In practice, we only synthesized members of enums
in this manner.
Because of this, SILGenModule::emitExternalDefinitions() had special logic to
skip members of enums, since it would visit them when visiting the enum itself.
Instead, it appears that we can remove implicitlyDefinedFunctions completely,
changing usage sites to add the decl to ExternalDefinitions instead, and
simplify SILGenModule::emitExternalDefinition() a bit in the process.
Also, it looks like we never had Modules appear in ExternalDefinitions, so
assert if those come up instead of skipping them.
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.
rdar://problem/23985987 has a crash report that implies that a null
snuck in here at some point in the past. All the refactoring that's
happened since then probably means it can't happen any more, but
assertions are always good, right?
Rather than plumbing a "has missing required members" flag all the way
through the LazyResolver's loadAllMembers and its implementations,
just eagerly update the "has missing required members" flag in the
Clang importer when it happens. More NFC cleanup.
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.
We were inferring protocol member availability as part of filling in
the complete imported protocol. Do it eagerly when we import a member
of a protocol.
Alternate declarations now capture all of the ways in which a single
Objective-C method can be reflected into two Swift methods (for
subscripts, factory-methods-as-initializers, and
instance-methods-as-class-methods).
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.
This method was only used for importing subscripts. Instead,
import a subscript when the imported name says we should (so we
eliminate the redundant check for "might this be a subscript
accessor?") and use the subscript "alternate declaration" to eliminate
the only other caller to importSpecialMethod.
When we are creating the complete list of imported members for an
Objective-C class or protocol, start relying on the "alternate
declarations" mapping to get the extra members. Do this only for
subscripts at the moment (now that they record alternate declarations
properly and are idempotent), but eventually we should expand this
out.
There was a lot of dodgy code in here that made subscript imports not
necessarily idempotent. Try to clean up the flow a bit, eliminating
the DeclContext parameter (which caused some "interesting" effects if
misused), be more methodical about handling the redeclaration case,
eliminate some unnecessary recursion due to performing name lookup in
the wrong place for override checking, etc.
We were depending on the (nearly) 1-1 mapping from Objective-C
selectors into Swift names when wiring up overrides of Objective-C
methods, but this mapping falls apart under
-enable-omit-needless-words. Use the Objective-C selector, which
represents the truth of overriding in Objective-C, to wire up
overrides properly.
There are some Clang declarations that end up being imported as
multiple declarations in Swift, e.g., CF types get imported both with
and without the "Ref" suffix, subscript getters get imported both as a
method and as a subscript, etc. Track this explicitly so it's easy to
query the alternate declaration of a given declaration for name
lookup.
In many of these cases, the alternate declarations should simply go
away, because they're bloating the API. But that's a Swift 3 change
that requires review. For now, we want parity between the behavior
without and with Swift name lookup tables.
We decided not to support "implicit" properties, where we import
getter/setter pairs as properties. Rather, we only import a property
when there is an explicit "@property" in Objective-C. Remove the flag
and supporting code for implicit properties.
Ensures that the Swift lookup tables get transformed name for imported
CF types, including original name (which is still
available). Otherwise, this is an NFC refactoring that gets the last
of the naming tricks into importFullName.
The translation from the Objective-C NSError** convention into Swift
throwing methods alters the names of methods. Move that computation
into importFullName. This should be NFC refactoring for everything
except the Swift name lookup tables, which will now correctly reflect
this name translation.
Yet more name-importing refactoring toward eliminating some redundant
code. As a drive-by, happens to fix swift_private imports for
no-parameter init methods.
