The type of non-strong properties is wrapped in a ReferenceStorageType,
which does not conform to Codable. This needs to be unwrapped so the
inner reference type can be considered for Codable conformance.
This time, the warnings only fire when the class in question directly
conforms to NSCoding. This avoids warning on cases where the user has
subclassed something like, oh, UIViewController, and has no intention
of writing it to a persistent file.
This also removes the warning for generic classes that conform to
NSCoding, for simplicity's sake. That means
'@NSKeyedArchiverEncodeNonGenericSubclassesOnly' is also being
removed.
Actually archiving a class with an unstable mangled name is still
considered problematic, but the compiler shouldn't emit diagnostics
unless it can be sure they are relevant.
rdar://problem/32314195
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
(...is constrained to be a subtype of another)
Previously the compiler would just mark the entry in the inheritance
clause invalid and move on without emitting any errors; in certain
circumstances in no-asserts builds this could actually lead to
everything working "correctly" if all conforming types happened to
pick the same concrete type for both associated types. In Swift 4 this
can actually be enforced with a same-type requirement, which will
guarantee that the two associated types are the same even in generic
contexts.
This fix avoids assertions and crashes, but the diagnostic is still
incorrect, and in the simple case of the inheritance clause it's
redundant. Doing something better and possibly even downgrading it to
a warning in Swift 3 mode is tracked by rdar://problem/32409449.
Initial patch by Slava, fixed up by me.
None of the clients of this care about distinguishing between immediate
failures in getWitnessType() vs. earlier errors that result in
getWitnessType() returning ErrorType, so simplify the interface by
having it always return Type() if there is a problem.
Update the clients that were not already checking for null result to do
so.
Fixes rdar://problem/32215763.
Protocol requirements involving same-type-to-Self constraints cannot
be witnessed by declarations in non-final classes that have the same
form of same-type requirement to the corresponding class type, because
it creates a soundness hole with subclasses:
protocol Q {
func foo<T: P>(_: T, _: T.T) where T.T == Self
}
class C: Q {
func foo<T: P>(_: T, _: C) where T.T == C {}
}
class D: C {
// in D, T.T == D does not hold
}
Warn about this in Swift 3 compatibility mode, error on it in Swift 4
mode. When possible, provide a note + Fix-It suggesting that the
same-type constraint might be weakened to a superclass constraint
(which works with subclassing).
Fixes rdar://problem/30398503.
Optional, Array, Set, and Dictionary currently all conform to Codable
regardless of the type they are generic on. Until conditional
conformance lands and we can rely on their conditional conformance, we
want to prevent Codable derived conformance if a type contains a
property of one of these types when we know it's actually going to fail
at runtime.
Adoption so far shows that the criteria we set up here are too broad.
This is particularly problematic for subclasses of NS/UIView and the
like that might never be encoded at all.
rdar://problem/32306355
* Introduce diagnostics that explain why derivation of
Encodable/Decodable fail rather than just silently failing
* Allow properties with default values to be omitted from CodingKeys
enum and from encoding/decoding
* If `CodingKeys` is a typealias, reach through it more consistently to
get at the final target type
* Add unit tests to confirm this new behavior for classes and structs
NOTE: Although this made the diff bigger, standalone variables named
"type" have been renamed to "target" throughout, since the word "type"
may be ambiguous and makes debugging impossible. "target" is unique.
Recursive concrete and superclass constraints are detected
per-equivalence-class; record them that way.
Use that information to drop recursive concrete and superclass
constraints from the resulting signature, which frees the canonical
generic signature builder from having to worry about such recursive
constraints. This eliminates the invalid-code crashes introduced in
the prior commit that disabled finalization for the canonical GSBs, as
well as fixing one other random crash-on-invalid.
This was added at some point with the associated type where
clause work, but it appears to be unnecessary, because all
the tests passed with this removed.
It also introduced a source compatibility issue where we
stopped accepting typealiases to protocol compositions in
protocol inheritance clauses.
Add a test for this case too, since it wasn't tested before.
Fixes <https://bugs.swift.org/browse/SR-4855>.
We can't reliably decide in the parser if a type was forgotten or a
wrong type was meant to be a type (e.g. `let x: class MyClass`).
This patch applies a heuristic that the parameter was most likely
forgotten if the next character is a closing bracket or a semantic
separator.
This catches the most common cases of function parameters and variable
declarations that are immediately initialised.
This fixes SR-4785.
Swift 3 allowed a class to explicitly conform to AnyObject, although
it was meaningless. Recent AnyObject-related changes started rejecting
such conformances as ill-formed; allow them with a warning + Fix-It in
Swift 3 compatibility mode.
When we have a potential assignment of associated types to type
witnesses during associated type inference, check that set of type
witnesses against the requirements in the requirement signature, so
that we can reject any solutions that fail some of the protocol's
requirements.
This is most of rdar://problem/31830524 --- but gets thwarted by the
inability of associated type inference to work across multiple
protocols.
Infer @_staticInitializeObjCMetadata in those cases where we need a
static initializer to make an NSCoding-conforming class visible to the
Objective-C runtime. This does *not* include classes with one of the
@NSKeyedArchive attributes:
* @NSKeyedArchiveLegacy implies that we'll register the class
directly, with the necessary side effect of initialize Objective-C
metadata.
* @NSKeyedArchiveSubclassesOnly promises not to archive the class
directly anyway.
Introduce the @NSKeyedArchiveSubclassesOnly attribute, which can be
placed on a class that conforms to NSCoding to suppress the
unstable-name diagnostics by promising to only archive
subclasses---not this class directly.
The diagnostic regarding NSCoding classes with unstable names can be
suppressed by adding @objc (the preferred solution for new code) or
@NSKeyedArchiveLegacy (for existing archives). Provide those as
Fix-Its, in that order.
(Thanks, Jordan!)
Currently inactive, this attribute indicates that a static initializer should be emitted to register the Objective-C metadata when the image is loaded, rather than on first use of the Objective-C metadata. Infer this attribute for NSCoding classes that won’t have static Objective-C metadata or have an @NSKeyedArchiveLegacy attributed.
This attribute allows one to provide the "legacy" name of a class for
the purposes of archival (via NSCoding). At the moment, it is only
useful for suppressing the warnings/errors about classes with unstable
archiving names.
The name mangling changed from Swift 3 to Swift 4, and may get slight
tweaks as we lock down ABI stability. Identify and warn about (in
Swift 3) or error about (in Swift 4) the cases where we don't have
obviously-stable name mangling, e.g.,
* private/fileprivate classes (whose mangled names involve the file name)
* nested classes (whose mangled names depend on their enclosing type)
* generic classes (whose mangled names involve the type arguments)
When an extension introduces a conformance that already exists, the
type checker will reject the conformance and then ignore it. In cases
where the original conformance is in the same module as the type or
protocol (but the new, redundant conformance is in some other module),
downgrade this error to a warning. This helps with library-evolution
cases where a library omitted a particular conformance for one of its
own types/protocols in a previous version, then introduces it in a new
version.
The specific driver for this is the conformance of String to
Collection, which affects source compatibility. Fixes
rdar://problem/31104415.
* Allow CodingKey conformance to be automatically derived for enums
which have no raw type (with no associated values) and which have
a raw type of String or Int.
* Allow Encodable and Decodable conformance to be automatically derived
for classes and structs with Encodable/Decodable properties
* Add initial unit tests for verifying derived conformance
Introduce a warning about redeclaring the associated types from an
inherited protocol in the protocol being checked:
* If the new declaration is an associated type, note that the
declaration could be replaced by requirements in the protocol's
where clause.
* If the new declaration is a typealias, note that it could be
replaced by a same-type constraint in the protocol's where clause.
Some messages said 'typealias' and others said 'type alias'.
Change everything to use 'type alias' consistently (except
when it's talking about the keyword itself).
