Unless -enable-resilient-objc-class-stubs is passed in, these cases
are not supported, so now we diagnose them instead of asserting or
failing to link.
Note the behavior change here; classes with resilient ancestry were
previously isObjC(). However this is wrong since isObjC() means
"statically visible to Objective-C via the generated header".
After this patch, isObjC() only returns true for a class with resilient
ancestry if -enable-resilient-objc-class-stubs is passed in.
We only ever use this in TBDGen and interface printing, and we only ever
generate TBD files or print interfaces for declarations in primary files,
so let's avoid unnecessary work in validateDecl().
Eventually we want validateDecl() to be replaced with a getInterfaceType()
request, so adding new attributes in this path (or other side effects in
general) is a big no-no.
It actually /does/ make sense to enforce the usable-from-inline rules
on dynamic declarations, but that would break source compatibility at
this point. Just allow '@usableFromInline' to be written on 'dynamic'
declarations, so that it'll be compatible with Swift 5.
In-place initialization means the class has a symbol we can reference
from the category, so there's nothing to do on the IRGen side.
For JIT mode, we just need to realize the class metadata by calling an
accessor instead of directly referencing the symbol though.
The information about whether a variable/property is initialized is lost in the
public interface, but is, unfortunately, required because it results in a symbol
for the initializer (if a class/struct `init` is inlined, it will call
initializers for properties that it doesn't initialize itself). This is
important to preserve for TBD file generation.
Using an attribute rather than just a bit on the VarDecl means this fits into
the scheme for module interfaces: textual/valid Swift.
...and collapse StaticVar/ClassVar and StaticLet/ClassLet into
StaticProperty/ClassProperty.
"var" and "let" aren't great nouns to use in diagnostics to begin with,
especially alongside semantic terms like "instance method". Focus on
the type vs. non-type aspect instead with "property", which better
matches how people talk about member vars (and lets) anyway.
Separate out the semantic state for the ‘dynamic’ check (from the
presence of the attribute), and move all of the computation of the
‘dynamic’ bit into the request-evaluator.
In the process, this fixes a bug where implicitly-synthesized initializers
in subclasses of imported classes would not be implicitly made ‘final’.
From the perspective of the compiler implementation, they're elements. But users will think of these as cases—and many diagnostics already refer to these as enum cases.
The “isObjC” bit, once computed, provides the authoritative answer. The presence of
ObjCAttr is mostly incidental, although an implicitly-created one is sometimes
needed to store additional information (“inferred with Swift 3 rules” and a
specific Objective-C name).
Previously we would produce a non-specific diagnostic about the
parameter type not being representable in Objective-C because
VarDecl::getType() wrapped the result in an InOutType.
Now that this is no longer the case we have to check for inout
independently of looking at the type.
Fixes <rdar://problem/41129106>.
Ownership keywords (weak/unmanaged) in @objc protocols do have an
effect on the generated header, because they get reflected as
weak/assign in the Objective-C `@property`. Therefore, allow these
keywords (again) on properties of @objc protocols.
Fixes SR-7182 / rdar://problem/38418112.
We accepted this in Xcode 9.2, but currently crash.
We may want to consider rejecting this entirely, but for now lets not
crash.
Fixes rdar://problem/36798061.
Attach this attribute to VarDecls declared as IUO, and to function decls
that have a result type that is an IUO.
NFC at the moment. Eventually we'll use these to determine where to
implicitly unwrap optional values.
As we do with "where" clauses, print the "inheritance" clauses of
protocols and associated type declarations using the requirement
signature of the protocol rather than the "inherited" list.
Due to the wanton use of 'if' rather than 'switch', non-observing,
non-get/set ccessors that got marked '@objc' would cause an
assertion. Fix the materializeForSet case from the bug report as well
as the addressor case.
Fixes SR-5025 / rdar://problem/32426538.
This is accomplished by recognizing this specific situation and
replacing the 'objc' attribute with a hidden '_objcRuntimeName'
attribute. This /only/ applies to classes that are themselves
non-generic (including any enclosing generic context) but that have
generic ancestry, and thus cannot be exposed directly to Objective-C.
This commit also eliminates '@NSKeyedArchiverClassName'. It was
decided that the distinction between '@NSKeyedArchiverClassName' and
'@objc' was too subtle to be worth explaining to developers, and that
any case where you'd use '@NSKeyedArchiverClassName' was already a
place where the ObjC name wasn't visible at compile time.
This commit does not update diagnostics to reflect this change; we're
going to change them anyway.
rdar://problem/32414557
@IBInspectable and @GKInspectable both work via the Objective-C
runtime. SE-0160 made them imply @objc, but doing so made it an error
to define an @IBInspectable or @GKInspectable property with a type
that could not be expressed in Objective-C. The attribute is useless,
but this broke Swift 3 code.
So, downgrade the error to a warning in Swift 3 compatibility mode,
with a Fix-It to remove the useless attribute. It remains an error in
Swift 4.
Fixes rdar://problem/31408971.
If the -enable-experimental-subclass-existentials staging flag
is on, resolveType() now allows protocol compositions to contain
class types. It also diagnoses if a composition has more than one
superclass requirement.
Also, change diagnostics that talked about 'protocol composition'
to 'protocol-constrained type'.
Since such types can now contain a superclass constraint, it's not
correct to call them protocol composition.
"Protocol-constrained type" isn't quite accurate either because
'Any' has no protocols, and 'AnyObject' will have no protocols but
a general class constraint; but those are edge cases which won't
come up in these diagnostics.
Introduce flags `-enable-swift3-objc-inference` and
`-disable-swift3-objc-inference` to enable/disable the Swift 3 `@objc`
inference rules. Under `-swift-version 3`, default to the former;
under `-swift-version 4`, default to the latter. For testing purposes,
one can provide either flag in eiher language mode.
