ObjC classes which have only factory and convenience initializers cannot allow their convenience inits to be inherited. To provide these classes with a reliable opt-out, tweak support for @_hasMissingDesignatedInitializers so that it affects ObjC classes even if they’re in the same module as one another.
Fixes rdar://48511013.
This test case tripped up an attempt I made to
simplify addImplicitInheritedConstructorsToClass
for clang decls. Add it to the test suite to make
sure we don't regress it.
This is reasonable to diagnose with a warning, but dropping the 'open'
down to 'public' isn't the right fix, because now it's not a valid
override. The declaration has to get moved to another extension instead,
or the extension has to not set a default access level.
This turned out to be a source compat issue because the same logic
that emits the fix-it also updates the access of the member, which
then resulted in "must be as accessible as the declaration it
overrides" in the /same/ build. It's not immediately clear what caused
this; probably something's just being validated in a different order
than it was before. The change makes sense either way.
Stepping back, it's weird that a warning would change how the compiler
saw the code, and while we could check for 'override' explicitly, we
can't know if the member might be satisfying a protocol requirement.
Better to just not guess at the right answer here.
rdar://problem/47557376&28493971
Objective-C allows this in "class extensions" (nameless categories);
what's worse is that it's actually useful-ish sometimes: when you want
to put a particular initializer in an explicit submodule, or only
expose it to the current target.
rdar://problem/37173549
Swift currently assumes that copies and deinitializations of C structs
are always "trivial", i.e. a copy can be done by just copying the raw
bits of the value, and a deinit requires no work at all. Until we do
anything to change that, just don't import any of the new C structs
that have non-trivial copy or deinitialization operations (those with
ARC references in them).
rdar://problem/35698831
Typedefs tend to be imported without bridging the underlying
type. However, when a typedef is used within a bridging context, we
should bridge based on the underlying type. That wasn't being done
consistently, causing us to import various typedefs without bridging
at all. Update the logic to use the bridged underlying type whenever
the (often unbridged) typedef type itself doesn't line up.
Fixes rdar://problem/34913507.
We just import this as a property, and Swift doesn't support
properties with dynamic Self type, even if they are read-only. Don't
mark the getter as returning dynamic Self in this case.
(This was only a problem in builds with the AST verifier turned on.)
https://bugs.swift.org/browse/SR-5684
In today's Swift, only non-optional function parameters can be
non-escaping (and are by default). An optional function parameter uses
a function type as a generic argument to Optional, and like any other
generics that's considered an opaque and therefore possibly escaping
use of the type. This is certainly unfortunate since it means a
function parameter cannot be both Optional and non-escaping.
However, this "unfortunate" becomes a concrete problem when dealing
with Objective-C, which /does/ allow applying its 'noescape' attribute
to a callback block marked 'nullable'. This is fine for /uses/ of
methods with such parameters, but prevents anyone from /overriding/
these methods.
This patch pokes a very narrow hole into the override checking to
accomodate this: if a declaration comes from Objective-C, and it has
an optional, non-escaping closure parameter, it's okay to override it
in Swift with an optional, escaping closure parameter. This isn't
strictly safe because a caller could be relying on the
non-escaping-ness, but we don't have anything better for now. (This
behavior will probably be deprecated in the future.)
(Some people have noted that the old 'noescape' type attribute in
Swift still works, albeit with a warning. That's not something people
should have to type, though---we want to remove it from the language,
as described in SE-0103.)
rdar://problem/32903155
This ensures that any @property redeclarations that appear in class
extensions (a special kind of category in ObjC) do not affect the
primary type of the property as declared in the class itself.
To accomplish this, lookups in importDecl that are checking for
conflicts now no longer pull in new categories/extensions if the
current context is a ClassDecl.
rdar://problem/30785976
The AST verifier is unhappy when an accessor's imported name gets
selector-split but its parameters don't have that recorded. Although
we're not using this for anything today, it seems best to keep the
two in sync.
rdar://problem/29889051
