If the Clang declrations are *types*, canonical declaration in Swift is
imported for newest version of Swift. In interface generation, if the
declaration is versioned and it's imported as a member in either or both
version of Swift, we have to take compatibility typealias into account.
* Fixed 'ClangModuleUnit::getTopLevelDecls' to take isCompatibilityAlias() into account
* Fixed bugs in ClangImporter where member-to-member versioned types aren't properly imported.
* Fixed 'SwiftDeclConverter::importFullName' to check equality of getEffectiveContext()
* Fixed 'importer::addEntryToLookupTable' to check equality of getEffectiveContext()
(moved 'ClangImporter::Implementation::forEachDistinctName' to 'NameImporter')
Still to do: test and fix up the use of multiple enum_extensibility
annotations, possibly with API notes. This is important because the
definition of NS/CF_ENUM /includes/ enum_extensibility(open) as of
Xcode 9.0; there should be a convenient out people can use to declare
exhaustive enums in C that's backwards-compatible.
Swift's ASTContext contained all of the logic to find the complete list
of properties for an Objective-C class, which is used by the Clang importer
to influence the mapping of Objective-C names into Swift. Swift's
ASTContext also included a *cache* for this information, indexed by
the Clang `ObjCInterfaceDecl *`. However, this cache was getting
populated/queried from the Clang importer's name importer, such that
the keys would be Clang declarations used to build modules and then
deallocated. If that memory eventually gets reused for a different
`ObjCInterfaceDecl *`, we would get incorrect/stale all-properties
information.
Almost Surely fixes rdar://problem/35347167, which is a
nondeterministic failure where UIView's `addGestureRecognizer(_:)` gets
occasionally imported as `add(_:)`.
*** Depends on Clang change "[APINotes] Record what version caused ***
*** an annotation to get replaced." Update your Clang checkout! ***
More generally, change the meaning of the SwiftVersions section in API
notes to be "this version or earlier" rather than "exactly this
version". We mostly get this behavior for free from the Clang-side
changes, but for SwiftName and the enum annotations we look at inactive
attributes as well. The latter is simple, but the former means being
careful about finding the annotation we /would/ have picked, i.e. the
one closest to the version we requested.
...so that we don't have to keep coming back to update it every major
release. And also so we can actually put methods on it instead of
using free functions.
No intended behavior change (yet).
Preparation for making ImportNameVersion a generalized struct rather
than an enum. We could have kept cramming it into a bitfield, sure,
but we don't actually need this.
No intended functionality change.
The etymology of these terms isn't about race, but "black" = "blocked"
and "white" = "allowed" isn't really a good look these days. In most
cases we weren't using these terms particularly precisely anyway, so
the rephrasing is actually an improvement.
This would fail later down the line anyway, meaning this does not
change the ultimate behavior of the importer, but since I added an
assertion that we're expecting a definition here in 2c68f8d49d, we
need to avoid even asking the question.
Also fix up a few other places where we aren't sure we'll have a
definition when calling these functions.
rdar://problem/33784466
Printing a declaration's name using `<<` and `getBaseName()` is be
independent of the return type of `getBaseName()` which will change in
the future from `Identifier` to `DeclBaseName`
Also lays the groundwork for rdar://problem/16513537, which is about
being able to find an enum by its original top-level name so that we
can show a diagnostic for that. I'll file a public bug about that
later.
rdar://problem/31893305
...and Swift 4 versions in Swift 3, and Swift 2 and "raw" versions in
both. This allows the compiler to produce sensible errors and fix-its
when someone uses the "wrong" name for an API. The diagnostics
certainly have room to improve, but at least the essentials are there.
Note that this commit only addresses /top-level/ decls, i.e. those
found by lookup into a module. We're still limited to producing all
members of a nominal type up front, so that'll require a slightly
different approach.
Part of rdar://problem/29170671
The next commit will make findSwiftNameAttr handle Swift 3 / Swift 4
API notes, so it's important that everything is consistently using it.
(The other place that isn't updated yet is enum info; conceivably, the
prefix for enum constants might be different based on which
SwiftNameAttrs are in play.
Extensive cross-language tooling support needs to bridge decl names between two different languages more freely. This SourceKit request is designed to translate Objc names to Swift names and vice versa. Working similarly to cursor-info requisition, the name translation request requires a Swift reference to a Swift/Clang decl, and the preferred name to translate from, and language kind that the given name belongs to. If the translation succeeds, SourceKit service responds with the corresponding name than belongs to the other kind of language.
Newly introduced keys:
“key.namekind": “source.lang.name.kind.objc” | "source.lang.name.kind.swift"
“key.basename”: “name"
“key.argnames”: [“name"]
“key.selectorpieces”: [“name[:]"]
This commit only implements translation from Objc to Swift.
Changes:
* Terminate all namespaces with the correct closing comment.
* Make sure argument names in comments match the corresponding parameter name.
* Remove redundant get() calls on smart pointers.
* Prefer using "override" or "final" instead of "virtual". Remove "virtual" where appropriate.
Remove all occurrences of a "useSwift2Name" bool, and replace it with
version plumbing. This means that ImportDecl is now entirely
version-based, and the importer Impl knows versions. This will be
needed for marking Swift 3 names as deprecated, when there is a new
Swift 4 name.
NFC.
Expose a ForeignErrorConvention::Info struct, so that the
ClangImporter can also utilize this space-efficient
storage. Eliminates the ClangImporter's ad-hoc representation, and
shaves off a pointer or so off of the ImportedName size.
While we're out it, make some of the bools bitfields to shave off
another pointer in size. Total ImportedName size is now 6.
Shave off a pointer from the EffectiveClangContext, by re-arranging
some of its data. Down to 2 pointers from 3.
Inside of ImportName, factor out the does-it-have-a-value from
multiple stored Optionals so as to shave off a couple of
pointers. Present the same programming interface as before. Down to 8
pointers in size from 10, and still much further to go.
Change the interfaces to ImportedName to be method based, rather than
direct struct field accesses. We're going to be changing how these are
used in the future. Also, we will be storing large quantities of
these, so we will soon want to crunch down on their size.
Rather than use importName using a set of options of what to choose,
phrase the API in terms of language version. Be explicit about what
version is being requested at the call site, as it's a necessary
consideration for the client.
Previously, for an Objective-C class method declaration that could be
imported as init, we were making 4 decls:
1) The Swift 2 init
2) The Swift 2 class method decl (suppressing init formation)
3) The Swift 3 init (omitting needless words)
4) The Swift 3 class method decl (suppressing init formation and
omitting needless words)
Decls 1), 2), and 4) exist for diagnostics and redirect the user at
3). But, 4) does not correspond to any actual Swift version name and
producing it correctly would require the user to understand how
omit-needless-words and other importer magic operates. It provides
very limited value and more importantly gets in the way of future
Clang importer refactoring. We’d like to turn Decl importing into
something that is simpler and language-version parameterized, but
there is no real Swift version to correspond to decl 4).
Therefore we will be making the following decls:
1) The "raw" decl, the name as it would appear to the user if they
copy-pasted Objective-C code
2) The name as it appeared in Swift 2 (which could be an init)
3) The name as it appeared in Swift 3 (which could be an init and omit
needless words)
This aligns with the language versions we want to import as in the
future: raw, swift2, swift3, …, and current.
Note that swift-ide-test prunes decls that are unavailable in the
current Swift version, so the Swift 2 non-init decls are not printed
out, though they are still present. Tests were updated and expanded to
ensure this was still the case.
If the keyword 'static' also appears within the '[' and ']' of the
array type derivation, then for each call to the function, the
value of the corresponding actual argument shall provide access to
the first element of an array with at least as many elements as
specified by the size expression. (C11 6.7.6.3p7)
Limit this change to Swift 4 so as not to break existing code, though
use of 'static' in this way is rare to begin with and passing nil
would probably be an error anyway.
Small part of rdar://problem/25846421.
