This patch adds warning for redundant access-level modifiers
used in an extension. It also refines the diagnostics of
access_control_ext_member_more issues, in case the fixit
could suggest redundant modifiers.
Resolves: SR-8453.
Technically, these operations belong in the ObjectiveC module, where NSObject
is defined. Keep them there. However, we need to build the mock ObjectiveC
overlay with `-disable-objc-attr-requires-foundation-module` now.
NSObject.hashValue is provided to satisfy the hashValue constraint of
the Hashable protocol. However, it is not the correct customization
point for interoperating with Objective-C, because Objective-C code
will call through the -hash method. Warn about overrides of
NSObject.hashValue; users should override NSObject.hash instead.
Fixes rdar://problem/42780635.
This allows them to be used in generic arguments for NSArray et al.
We already do this for the ones that wrap bridged values (like
NSString/String), but failed to do it for objects that /weren't/
bridged to Swift values (class instances and protocol compositions),
or for Error-which-is-special.
In addition to this being a sensible thing to do, /not/ doing this led
to IRGen getting very confused (i.e. crashing) when we imported a
Objective-C protocol that actually used an NS_TYPED_ENUM in this way.
(We actually shouldn't be using Swift's IRGen logic to emit protocol
descriptors for imported protocols at all, because it's possible we
weren't able to import all the requirements. But that's a separate
issue.)
https://bugs.swift.org/browse/SR-6844
Karoly removed the last use of _convertStringToNSString in f2a96496a;
the replacement is referenced by the runtime but not by the compiler.
Doug had removed all the others from the stdlib in d92ae7707.
rdar://problem/35230338
* [runtime] Clean up symbols in error machinery.
* [runtime] Clean up symbols in Foundation overlay.
* [runtime] Clean up symbols in collections and hashing.
* [runtime] Remove symbol controls from the Linux definition of swift_allocError.
* [tests] Add more stub functions for tests that link directly to the runtime.
Overriding of members introduced in class extensions depends on the
presence of an Objective-C entrypoint. When we override such a
member---which used the deprecated @objc inference rule and occurs in
a class extension, where non-@objc methods currently cannot be
overridden---warn about the use of explicit @objc.
Actually bridging ObjCBool to Bool is overkill for this, but moreover
it caused problems for non-boolean types that took this code
path. Just go back to the previous logic of unwrapping multiple levels
of struct; this way we can also handle wrappers around integer types
(if we ever have any).
rdar://problem/27985744
SE-0072 took implicit bridging conversions away, which regressed the ability to express NSDictionaries as dictionary literals and index them using literal keys. Address this by changing the signature of init(dictionaryLiteral:) to use Hashable and Any, and by replacing the subscript from Objective-C with one using _Hashable that does the bridging on the user's behalf. This largely restores the QoI of working with NS collections.
Attempting to throw an error code value, e.g.,
throw CocoaError.fileNoSuchFileError
is now ill-formed, although it was well-formed prior to the
introduction of NSError bridging (SE-0112). Provide a specialized
diagnostic with a Fix-It to add the appropriate parentheses:
throw CocoaError(.fileNoSuchFileError)
Fixes rdar://problem/27543121.
We would crash because 'Any' doesn't have a corresponding bridged type through the normal bridging mechanism. Handle this correctly, and correctly recognize 'AnyHashable' and 'Any' as the upper bounds of Dictionary, Set, and Array so we present the unqualified NS types in the generated header.
This lets us eliminate the _getObjectiveCType() value witness, which
was working around the lack of proper type witness metadata in witness
tables. Boilerplate -= 1.
This reverts commit 052d2d0a69.
The only actual issue with the original change was a missing change to
the UIApplicationMain SILGen test, which needs to build SILGen
overlays to execute properly; -enable-source-import doesn't suffice.
Introduce a new entrypoint to _ObjectiveCBridgeable,
_unconditionallyBridgeFromObjectiveC, which handles unconditional
bridging from an optional Objective-C object (e.g., an NSString) to
its bridged Swift type. Use it in SILGen to perform NSString -> String
bridging rather than the custom entry point.
Another small step toward generalized bridging.
Introduce Fix-Its to aid migration from selectors spelled as string
literals ("foo:bar:", which is deprecated), as well as from
construction of Selector instances from string literals
(Selector("foo:bar"), which is still acceptable but not recommended),
to the #selector syntax. Jump through some hoops to disambiguate
method references if there are overloads:
fixits.swift:51:7: warning: use of string literal for Objective-C
selectors is deprecated; use '#selector' instead
_ = "overloadedWithInt:" as Selector
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
#selector(Bar.overloaded(_:) as (Bar) -> (Int) -> ())
In the cases where we cannot provide a Fix-It to a #selector
expression, we wrap the string literal in a Selector(...) construction
to suppress the deprecation warning. These are also easily searchable
in the code base.
This also means we're doing more validation of the string literals
that go into Selector, i.e., that they are well-formed selectors and
that we know about some method that is @objc and has that
selector. We'll warn if either is untrue.
This reflects the fact that the attribute's only for compiler-internal use, and isn't really equivalent to C's asm attribute, since it doesn't change the calling convention to be C-compatible.
At some point I want to propose a revised model for exports, but for now
just mark that support for '@exported' is still experimental and subject
to change. (Thanks, Max.)
The -enable-omit-needless-words option attempts to omit needless words
from method names imported from Clang. Broadly speaking, a word is
needless if it merely restates the type of the corresponding parameter,
using reverse camel-case matching of the type name to the
function/parameter name. The word "With" is also considered needless
if whether follows it is needless, e.g.,
func copyWithZone(zone: NSZone)
gets reduced to
func copy(zone: NSZone)
because "Zone" merely restates type information and the remaining,
trailing "With" is also needless.
There are some special type naming rules for builtin Objective-C types,
e.g.,
id -> "Object"
SEL -> "Selector"
Block pointer types -> "Block"
as well as some very-Cocoa-specific matching rules, e.g., the type
"IndexSet" matches the name "Indexes" or "Indices".
Expect a lot of churn with these heuristics; this is part of
rdar://problem/22232287.
Swift SVN r31178
The internal details of ErrorType are still being designed.
They should be underscored in the meantime to
indicate they are still evolving.
Implements rdar://problem/20927102.
Swift SVN r28500
The string version of r26479. There's a lot of backstory and justification
there, so just read that commit message again. The one addition for String
is that global NSString constants are loaded as String as well, so that
also has to go through the bridging code even though there's no function
call involved.
Finishes rdar://problem/19734621.
Swift SVN r26510
...and similar for NSDictionary and NSSet.
For APIs that don't have a reason to distinguish "empty" and "absent" cases,
we encourage standardizing on "empty" and marking the result as non-optional
(or in Objective-C, __nonnull). However, there are system APIs whose
implementations currently do return nil rather than an empty collection
instance. In these cases, we recommend /changing/ the API to return the
appropriate "empty" value instead.
However, this can cause problems for backwards-deployment: while the API is
truly non-optional on system vN, a program may encounter a nil return value
if run on system vN-1. Objective-C can generally deal with this (especially
if the only thing you do is ask for the count or try to iterate over the
collection) but Swift can't. Therefore, we've decided to "play nice" and
accept nil return values for the collection types (NSArray, NSDictionary,
and NSSet) and implicitly treat them as "empty" values if they are the
result of an imported function or method.
Note that the current implementation has a hole regarding subscript getters,
since we still make an AST-level thunk for these in the Clang importer.
We can probably get rid of those these days, but I didn't want to touch
them at this point. It seems unlikely that there will be a subscript that
(a) is for a collection type, and (b) mistakenly returned nil in the past
rather than an empty collection.
There's another hole where an ObjC client calls one of these mistakenly-nil-
returning methods and then immediately hands the result off by calling a
Swift method. However, we have to draw the line somewhere.
(We're actually going to do this for strings as well; coming soon.)
rdar://problem/19734621
Swift SVN r26479
While Foundation actually defines the NSZone typedef and what you can do with
it, the ObjectiveC module makes use of it in its raw form: "struct _NSZone *".
To avoid a circular dependency, sink our adapter down to the ObjectiveC
overlay.
Swift SVN r21827
The _forceBridgeFromObjectiveC and _conditionallyBridgeFromObjectiveC
requirements of the _ObjectiveCBridgeable protocol previously returned
Self and Self?, respectively, where 'Self' is the value type that is
bridged. This use of returns is fairly hostile to the idea of calling
the witnesses for these requirements from the C++ part of the runtime,
leading to "interesting" tricks with OpaqueExistentialContainer that
made it hard to use these witnesses within the dynamic casting
infrastructure.
Replace the returns with inout Self? parameters, which are far easier
to deal with in the C++ part of the runtime. Despite the churn because
we're changing the _ObjectiveCBridgeable protocol, this is NFC.
Swift SVN r20934
