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.)
We now specially import global decls who we identify as fitting the
notification pattern: extern NSStrings whose name ends in
"Notification". When we see them, we import them as a member of
NSNotificationName and, if NSNotificationName is swift_newtype-ed, we
use that new type.
Test cases included.
When attempting to compile Swift 2 code (or any Swift code using the
Swift 2 names) in Swift 3, the compiler diagnostics are often entirely
useless because the names have changed radically enough that one
generally gets "no member named 'foo'" errors rather than a helpful
"'foo' was renamed to 'bar'" error. This makes for a very poor user
experience when (e.g.) trying to move Swift 2 code forward to Swift 3.
To improve the experience, when the Swift 2 and Swift 3 names of an
API differ, the Clang importer will produce a "stub" declaration that
matches the Swift 2 API. That stub will be marked with a synthesized
attribute
@available(unavailable, renamed: "the-swift-3-name")
that enables better diagnostics (e.g., "'foo' is unavailable: renamed
to 'bar') along with Fix-Its (courtesy of @jrose-apple's recent work)
that fix the Swift 2 code to compile in Swift 3.
This change addresses much of rdar://problem/25309323 (concerning QoI
of Swift 2 code compiled with a Swift 3 compiler), but some cleanup
remains.
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.
When an Objective-C class type is annotated with the swift_bridge
value type, bridge it to the named type. Use API notes on Foundation
rather than special cases.
For Objective-C classes where bridging was baked into the Clang
importer (NSString, NSArray, NSDictionary, NSSet), add API notes to
put the appropriate swift_bridge attribute on these Objective-C
classes.
Note: requires Clang update.
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.
This is more of rdar://problem/24869070; StringRefs are leaking out of
importFullName still, in a DenseMap that can get deallocated. When we
cache this data, put them in "permanent" (Swift ASTContext) storage.
Also, make the cache kick in between when a module is built and when
it is used. This isn't actually an important case, but it makes it a
whole lot more common to actually see the use-after-free break things.
Fixes rdar://problem/24869070.
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 importing as a member, we want a single unique extension
declaration per type per Clang submodule. This adds the mapping,
switches import-as-member VarDecl importing to use it, and forces the
created extensions to show up.
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]
Previously, the "effective context" parameter to importFullName was
used only during the construction of Swift name lookup tables, so we
can associate each declaration with a context. Expand the role of
"effective context" so it is always a part of ImportedName and is also
used by importDecl when actually importing the enum declaration.
This is partially a cleanup, and partially staging for SE-0033, which
will require this functionality more broadly.
This reorganization allows adding attributes that refer to types.
I need this for a @_specialize attribute with a type list.
PrintOptions.h and other headers depend on these enums. But Attr.h
defines a lot of classes that almost never need to be included.
Rather than managing API notes directly in the Clang importer, tell
Clang where to find the API notes files and let it map them directly
to attributes. Then, use the existing attribute-mapping
mechanisms---with minor extensions for cases where Clang previously
didn't map some Swift-specific API notes---to get at that information.
There is a minor regression where we can no longer apply API notes to
declarations that don't have a specific Clang declaration. The
specific example (NSError's inherited init()) comes from
rdar://problem/21042412; we've regressed here, but the correct fix is
(and has always been) on the Objective-C side
(rdar://problem/19977891).
Finishes rdar://problem/24447420.
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.
Caching information based on Clang declaration pointers, when that
information is used via importFullName, is unsafe because the
declaration pointers may point into Clang AST contexts built
temporarily built for modules, and therefore go stale. I believe this
is the cause of the recent ASan failures.
Again, the whole passing-through-a-different-Clang-Sema thing with
importFullName is an architectural fail that requires refactoring, so
we don't keep falling into this trap.
Introduces new class, EnumInfo, just for the implementation of the
ClangImporter to encapsulate various computed information about the
enum we're importing.
This helps refactor some functionality, aids clarity, and also
prevents us from repeating calculations multiple times, as we were
doing with classifyEnum's macro-expansion tracking. Provides a base
where we can add more heavy lifting in classifyEnum in the future.
