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.
Refactoring that lets the Swift lookup tables get the names right for
Objective-C protocols that would conflict with another entity in the
same module (or within the bridging header). It's an NFC cleanup
everywhere else.
Centralize the mapping of C names to Swift names further by including
enumerator prefix stripping, rather than having that as a separate
path. The actual logic and code for computing the prefix is unchanged
(despite moving from one file to another). This corrects the name
computed for the Swift lookup tables, but is an NFC refactoring for
everything else.
With this, kill off importName(), because it's been entirely
superseded by importFullName().
This places enumerators that will become either cases of a Swift enum
or options in a Swift option into the context of the C enum type for
the name lookup table.
The sole remaining caller to importName is for enumerators, which may
have prefixes that need stripping. That refactor will come in a
subsequent commit.
The Swift lookup tables are the primary client and test vehicle right
now. This change adds the capability to use the swift_name attribute
to rename C functions when they are imported into Swift, as well as
handling the swift_private attribute more uniformly.
There are a few obvious places where I've applied this API to
eliminate redundancy. Expect it to broaden as the API fills out more.
This required a few changes in places where we synthesize functions to
make sure these properties hold. That's good because we don't know where
we might already be depending on them. (On the other hand, we could also
decide not to care about TuplePattern labels, in which case I wonder if
we could eventually discard them altogether in functions.)
Still untested: that the function type is also in sync.
This is functional for arbitrary Objective-C properties and methods
(the subject of rdar://problem/22214302), as well as for changing the
argument labels of C functions. However, it does not work when the
name of a global is changed because name lookup initiated from
Swift goes through the Swift lookup table. Fixes
rdar://problem/22214302 but is only a step toward
rdar://problem/17184411.
Swift SVN r32670
This is all effectively NFC, but lays out the shape of the iterative
type checker: requests are packaged up in TypeCheckRequest, we can
check whether the request has been satisfied already (isSatisfied),
enumerate its dependencies (enumerateDependenciesOf) in terms of other
TypeCheckRequests, and satisfy a request (satisfy).
Lazily-computed semantic information is captured directly in the
AST, but has been set aside in its own structure to allow us to
experiment with moving it into a lookaside table.
The only request that exists now is to type-check the superclass of
the given class. It currently performs unhealthy recursion into the
existing type checker. As we detangle dependencies, this recursion
between the IterativeTypeChecker and the TypeChecker can go away.
Swift SVN r32558
...or rather, typealiases of AnyObject. They should be typealiases of
CFTypeRef. (The problem is that everywhere else CFFooRef becomes a typealias
for CFFoo, but we don't do the same with 'CFType'.)
Fixes a PrintAsObjC problem where we'd try to mark such typealiases as
'strong' if they show up in the generated ObjC header.
rdar://problem/22827172
Swift SVN r32230
