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.
The three varieties of 'pending callbacks' made it hard to reason about
how callbacks would be presented to subclasses of ASTPrinter. I
recently added new callbacks that would have made this even more complex
to deal with.
Luckily, it turns out they weren't buying us much, and simply forcing
any pending newlines and indentation to be printed ahead of making
callbacks was almost identical to the old behaviour. One complication is
that we now need to check for clang doc comments up front so we will
emit a newline in the right place.
This also incidentally fixed a bug in Loc vs Decl callback order.
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.
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.
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.
Splitting *before* the last preposition tends to keep the
prepositional phrase together. Only leave the preposition on the base
name in rare cases where we would end up with weird argument labels
(e.g., prefer "moveTo(x:y:)" to "move(toX:y:)").
Also, refine our heuristics for when we can remove the preposition
entirely.
