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.
In C, macros can be redefined so long as the redefinitions are
tokenwise equivalent. Provide the Clang importer with the same ability by
determining when tokenwise equivalent macros would be imported as
different Swift declarations, and collapse them into a single
declaration.
When we're omitting needless words and building Swift name lookup
tables, make sure to use the proper Clang
Sema/Preprocessor/ASTContext. This still needs to be properly
detangled, but at least now we can handle omit-needless-words for
builtin Clang types (e.g., SEL) properly.
As part of this, put OmitNeedlessWords and InferDefaultArguments into
the module file extension hash for the Swift name lookup tables, since
those settings will affect the results.
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.
Omitting needless words while importing the full name function
involves inference of default arguments, so we can get here while
building Swift name lookup tables. It takes a lot of machinery to
trigger this problem; tests forthcoming.
There *must* be a better way to ensure this never happens, but it
requires a bit more refactoring in the Clang importer.
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.
The recently-introduced module file extensions functionality in Clang
allows us to piggy-back the Swift name lookup tables in Clang's module
files. When the Swift name lookup tables are enabled, introduce such a
module file extension, and wire it into the SwiftLookupTable.
The actual contents of the extension block are simple: a single
on-disk hash table mapping base names to "full entries", which store
the context (e.g., a class, protocol, tag, or TU) and the set of
declarations.
Allow lazy resolution of declaration IDs deserialized from the
extension block to Clang declarations, to try to minimize the set of
declarations we must deserialize. Name lookup itself is only used to
dump the Swift name lookup tables and ensure we're round-tripping
properly.
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.
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.
This is needed for member lookup via the Swift lookup tables, although
the lookup part is not yet implemented. Note also that the results are
currently wrong for C enumerations mapped into Swift enums or option
sets. That will come shortly.
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.
When we parse a bridging header, start building a mapping from Swift
names (both base names and full names) to the Clang declarations that
have those names in particular Clang contexts. For now, just provide
the ability to build the table (barely) and dump it out; we'll grow
it's contents in time.
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
Instead, when mapping a Clang type to its name for omission purposes,
map CF types to their appropriate names. This more directly mirrors
what will happen on the Swift side, but is otherwise NFC.
Swift SVN r32140
Split the base name at the last preposition, but *only* when the first
parameter is defaulted, because defaulted arguments might not show up
at the call site and the longer base name can feel odd in such
cases. With this, stop avoiding the argument label "with": it's fine
when we have actual context at the call site, and the "with: nil" case
no longer happens now that we're defaulting nil.
Swift SVN r32098
My temporary hackery around inferring default arguments from imported
APIs was too horrible. Make it slightly more sane by:
1) Actually marking these as default arguments in the type system,
rather than doing everything outside of the type system. This is a
step closer to what we would really do, if we go in this
direction. Put it behind the new -frontend flag
-enable-infer-default-arguments.
2) Only inferring a default argument from option sets and from
explicitly "nullable" parameters, as stated in the (Objective-)C API
or API notes. This eliminates a pile of spurious, non-sensical "=
nil"'s in the resulting output.
Note that there is one ugly tweak to the overloading rules to prefer
declarations with fewer defaulted arguments. This is a bad
implementation of what is probably a reasonable rule (prefer to bind
fewer default arguments), which intentionally only kicks in when we're
dealing with imported APIs that have default arguments.
Swift SVN r32078
When the type name we're looking at is a collection of some element
type, also try to match the plural form of the element type name. For
example:
- func deselectItemsAtIndexPaths(_: Set<NSIndexPath>)
+ func deselectItemsAt(_: Set<NSIndexPath>)
Swift SVN r31666
Some GCD APIs rely on the pointer identity of blocks, so avoid bridging
when possible. The easiest way to do this was to use our existing rules
for special-casing typedefs.
The summary text for dispatch_block_t comes from the actual GCD headers.
rdar://problem/22432170
Swift SVN r31634
...when importing NSUInteger. Stop pretending it means anything else.
No functionality change; groundwork for rdar://problem/19134055.
Swift SVN r31353
