While inferring get/set, we paired them up even when one of them was
available through a custom objc header (e.g. a private
header). Instead, fail to pair them up. Test case added.
It's possible for swift_name to make a global declaration into a
member of another entity that has not been seen yet. In such cases,
delay resolution until the end of the translation unit (module). Fixes
the rest of rdar://problem/25502497.
Some of the callers to importDeclContextOf could and should have
passed an effective context, but didn't, so (e.g.) an enum defined in
C couldn't be mapped to a nested type in Swift. Eliminate the
single-argument importDeclContextOf honeypot so we remember to pass
down the effective Clang context. Fixes rdar://problem/25502497.
In the Clang importer, and only in submodules, the first protocol
typedef with NSObject that we try to import results in a hidden lookup
result. So, allow hidden lookups, which is benign and failure is
actually an issue of a malformed header. Gracefully handles failure.
Test case included that will reproduce the issue if AllowHidden is
disabled.
There's an odd, and unknown bug in the Clang Importer where we seem to
fail a Clang lookup of NSObject the very first time we try. While I'm
still diagnosing this, un-block SILGen work.
Introduce abstraction patterns for curried C-functions-as-methods for type lowering, and plumb the "foreign self parameter index" through call emission so that we emit the "self" parameter in the right position. This gets us handling C functions imported as methods with explicit swift_name attributes in simple, fully-applied cases. There's still more work to be done for properties, partial applications, and initializers introduced by extensions.
Adds incremental de-sugaring to any non-CF typedefs we find in our
types when trying to determine the effective DC. Additionally, cleans
up some logic and allows us to fail earlier on types we cannot
possibly extend.
This hooks up omitNeedlessWords to import as member.
Unfortunately, we are now left straddling different approaches to
handling our strings, I'll be refactoring that soon.
Introduces validToImportAsProperty, which has to perform extra
checking the make sure that a get/set pair are compatible with import
as a property. This includes matching up 'self' parameters, matching
get's return type with the set's argument type, etc. Includes more
extensive tests.
Expands support for inference of computed properties, whether instance
or static, to include get-only. Adds test cases for both inference and
manual annotation for static computed properties.
When a global function is determined to be a lone getter or a
getter/setter pair, import it as a property. Handle global, instance,
and static properties.
As part of this, generalize importAsMethod to also handle static
methods and map pointer-to-non-const arguments to 'mutating' methods.
When printing the interface for a (sub)module, make sure that we only
print those extensions that were created to hold that submodule's
globals that were imported as members.
Print module functionality hooked up to import global functions a
methods, if dictated by the swift_name attribute. Test case included.
No SILGen support yet.
Wire up the extensions created when importing globals-as-members via
the same mechanisms we use for Objective-C categories, e.g.,
implementing loadAllExtensions() to find the extensions and lazily
loading their members via the member loader. Addresses most of my
comments on the way extensions were wired in.
Extend our testing for importing globals as members to two different
submodules, so we can see the separation of extensions.
As part of this, fold getOrCreateExtension into importDeclContextOf.
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.
