There's really not that much code shared between the accessor and
non-accessor cases in importMethodType, so split them up.
The one change here is that previously a method could /think/ it was
an accessor, but not be treated as one if the property decl has a
different getter or setter. Now such a method is just dropped by the
importer completely. It's intended that this is not a behavioral
change in that no real code should have such an AST.
This is building towards always having a consistent type for property
setters added in handlePropertyRedeclaration, which is
rdar://problem/29422993.
Once upon a time this was agnostic of the declaration being imported
(and possibly even still merged with importFunctionType) but that
hasn't been true for a while. If we're passing the ObjCMethodDecl
and ImportedName anyway, we don't need to separately pass the result
type, whether it's noreturn, and the Swift name as separate arguments.
No intended functionality change.
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.
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.
ImportDecl has an alternate decl quasi-escape-hatch where it can
create alternative declarations for the same original Clang node. But,
it was limited at one, which worked accidentally in the case of
VisitObjCMethodDecl's attempts at importing a factory-init-suppressed
root-class method that points to the imported-as-init Swift
declaration.
This commit changes that to a TinyPtrVector, to support the upcoming
occasional case where we have more.
Drop the ImportNameSwiftContext, which was merely used to pass around
some global state. Instead, pass the relevant parts
directly. Additionally, remove the 2-phase initialization of a
NameImporter from the module writers, as they are only invoked once
per Clang instance anyways, we can hold a local instance. Also
streamlines some APIs.
NFC
During normal import, the name for a foreign entity may be requested
many times. As we have more and more complex logic to compute these
new names, the overhead of potential re-computations adds up. This
cache is hit about 1/3rd of the time when running a simple
CoreGraphics test case.
NFC
Now that we have per-Clang-instance NameImporters, we can drop the
2-phase initialization that was internally present in
NameImporter. This lets NameImporter host the EnumInfoCache directly,
and streamlines the APIs.
NFC
Banish the abomination that is clangSemaOverride, a previously
necessary evil. When building the module caches, different Clang
instances will be spawned than the one used by the normal
importer. Since we want to reuse code and get the same name both ways,
this meant threading through alternative clang Semas and preprocessors
throughtout, some of the time. This broke the abstraction and
encapsulation of the Impl, complicated the programming model, and
otherwise made effective caching hard.
Now that we’ve done enough ImportName refactoring, we can create a
NameImporter per Clang instance, and encapsulate naming therein. We
can now remove the sema overrides, as we have already done to the
preprocessor overrides.
This shifts the 2-phase initialization problem to the Impl and the
Clang module writers.
NFC
Delay initialization of the EnumInfoCache until a Clang instance is
ready, simplifying its interface and allowing us to finally make this
per-Clang-instance. This will allow us to further de-couple ImportName
from the importer imply, as well as allow us to use a more efficient
and simpler caching mechanism. It is now owned by the NameImporter.
NFC.
SwiftNameLookupExtension and ClangImporter::Implementation were
friends, but as time goes on they have drifted apart. As part of the
ImportName refactoring, these are being decoupled to facilitate
multiple-name importing, and fight the existing false encapsulation
present in the Impl.
SwiftNameLookupExtension is now spun off into its own entity, and can
evolve to have and use its own de-coupled NameImporter.
Finally, SwiftNameLookupExtension no longer stors a reference to
ClangImporter::Implementation, a false encapsulation. Instead, it uses
a NameImporter of its own, and merely keeps a reference to the lookup
table map.
Future directions include making the NameImporter specific to a Clang
instance, meaning that we can effectively cache Clang entities better
(and not resort to EnumInfoCache's stringly keyed caches). We can also
then drop all notions of a "ClangOverride" and other messy phase
entanglement.
NFC
Change more methods on the Impl to be static, passing down an
ASTContext if necessary. While this does ugly up the functions
slightly with the extra parameter, it decouples them from the Impl,
which has been a false abstraction when building the lookup
tables. These can all be moved to a more appropriate place in the
future.
NFC
addEntryToLookupTable is one of the laggards holding back the
Impl-free Clang lookup table effort. Make a static variant, now that
we have the convenient NameImporter.
NFC
Name Importer wraps references to the Swift context and other needed
encapsulation. The eventual goal is to allow name lookup tables to
live separately from the Impl, and do better Clang-instance-based
caching in the future, as well as general separation of concerns.
NFC
Pull omitNeedlessWordsInFunctionName off of the Impl, and into a
static function local to ImportName.cpp. Separate it out from the Impl
entirely. Though this adds a couple of extra ugly parameters, it's one
of the last bits of tie-in between importFullName and the Impl.
By refactoring out PlatformAvailability from the ClangImporter, we can
more easily refactor out isUnavailableInSwift from the impl, which
will free us up to do more flexible import naming.
Introduces new files ClangAdapter.h/cpp, which will serve as a
convenient place to put code reasoning about Clang details. Refactors
out most Clang-related is*, has*, and get* methods from the
ImporterImpl. In the future, an adapter class could help serve to
seperate the concerns of the importer from the details of how to
correctly use Clang APIs.
Pull off the caching code from the Impl and onto a new EnumInfoCache
class, that will be useful as we decouple import naming from the Impl
class state.
Refactors out some definitions and types from the
ClangImporter::Implementation into a new component ImportName. Future
work will include more separation and finally some redesigning of name
determination components.
...to value types. Do continue bridging BOOL to Bool and such.
If the Objective-C API author went out of their way to indicate
ownership, they're probably using the reference semantics for
something. Give them the benefit of the doubt and leave the properties
declared using reference types. (It's not that they wouldn't work
correctly using Any, but that it's obscuring the intended interface.
And any /specific/ bridged value types /might/ actually cause issues
by causing copies.)
There is one wrinkle here involving declarations in the "accessibility
protocols" on Apple platforms, which sometimes use methods and
sometimes properties. The Swift compiler already deals with these by
always importing these as methods, so treat these like any other
methods and use value types when relevant.
rdar://problem/27526957
We now just take the property type directly in all cases where it
matters, and the original case for which it was added, the Void return
of a setter, is handled fine by the normal AuditedResult kind.
No functionality change.
One minor revision: this lifts the proposed restriction against
overriding a non-open method with an open one. On reflection,
that was inconsistent with the existing rule permitting non-public
methods to be overridden with public ones. The restriction on
subclassing a non-open class with an open class remains, and is
in fact consistent with the existing access rule.
'fileprivate' is considered a broader level of access than 'private',
but for now both of them are still available to the entire file. This
is intended as a migration aid.
One interesting fallout of the "access scope" model described in
758cf64 is that something declared 'private' at file scope is actually
treated as 'fileprivate' for diagnostic purposes. This is something
we can fix later, once the full model is in place. (It's not really
/wrong/ in that they have identical behavior, but diagnostics still
shouldn't refer to a type explicitly declared 'private' as
'fileprivate'.)
As a note, ValueDecl::getEffectiveAccess will always return 'FilePrivate'
rather than 'Private'; for purposes of optimization and code generation,
we should never try to distinguish these two cases.
This should have essentially no effect on code that's /not/ using
'fileprivate' other than altered diagnostics.
Progress on SE-0025 ('fileprivate' and 'private')
Before we would construct types containing a mix of interface and
contextual types, and then map them in and out. Straighten this out.
Note that I've also had to start untangling the issue where
synthesized ParamDecls do not have an interface type.
We map clang::AvailabilityAttr::getReplacement() to
swift::AvailableAttr::Rename, transforming the replacement
name using by looking up the named Clang replacement, and
importing its name.
Fixes <rdar://problem/26301742>.
Due to swift_name and swift_newtype, we are frequently importing onto
different contexts. This was confusing the fixit logic for unavailable
swift2 names, as we were trying to use Clang names when the Swift name
might be totally different (and even a nested type). This change has a
two-fold effect:
1) Globals who are imported onto swift_newtype-ed typedefs should be
considered ImportAsMember.
2) When printing out the name of an ImportAsMember Swift 3 decl, we
need to print out a fully qualified context, which also uses the
Swift names, not the Clang names.
The IntPtrPair will do a sizeof on the ClangModuleUnit, which requires a
complete definition. Use the include rather than create a forward declaration.
More generally, an unavailable initializer shouldn't stomp on an
available initializer, because it's possible that (for example) a
designated initializer will be unavailable but a factory initializer
will be available, so one still construct objects of that type.
Fixes rdar://problem/26238032.
Previously we imported a Core Foundation type "CCFooRef" as "CCFoo",
but also provided a typealias "CCFooRef". In Swift 3, we decided to
mark "CCFooRef" unavailable to force developers to consistently use
"CCFoo". Now that we have infrastructure to mark /all/ renamed
declarations as unavailable, just use that to track the renaming,
i.e. pretend that "CCFooRef" was the "Swift 2" name for the type.
This doesn't change the conflict resolution behavior: if there's
another name "CCFoo" in the same module, the CF type will be
imported as just "CCFooRef".
Groundwork cleanup for rdar://problem/26347297, which notes that our
import-as-member fix-its use the "Ref" names rather than the short
names.
More specifically, don't include declarations of methods and properties
in the list of "all imported Objective-C members" if said method or
property is in a generated header. (We actually key off of whether the
enclosing class, protocol, or category is marked as coming from Swift,
but since users aren't supposed to modify generated headers themselves
it's much the same thing.)
This previously caused a crash because we tried to import a Clang member
onto a Swift decl in order to provide the particular member on AnyObject.
rdar://problem/25955831 and probably also rdar://problem/25828987, which
deals with the fix-it to migrate to #selector. (We do an AnyObject-like
lookup to find out which class likely implements the specified selector.)
