* Use `isSpecificProtocol` instead of `==`
* Synthesize Encodable implementation lazily
* Don’t mark conformances as Used when they don’t need to be
* Avoid creating explicit one-element arrays
* Use lookupDirect instead of walking AST manually
* Produce diagnostic for Decodable classes whose non-Decodable superclass has a failable init
* Filter lazy vars manually since getStoredProperties() does not always do so
* Amend Decodable class diagnostic text
* Check for enum RawType errors only if the type was already validated
* Update unit tests to match changes
Classes which receive a synthesized Decodable implementation should be able to subclass non-Decodable classes (if the superclass has an accessible init()) method.
Also improve diagnostics when this is not the case.
In anticipation of future attributes, and perhaps the ability to
declare lvalues with specifiers other than 'let' and 'var', expand
the "isLet" bit into a more general "specifier" field.
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.
Codable failures produced diagnostics and notes explaining what failed
during decode. These diagnostics were being output as they were
generated, which was suboptimal because it meant that NOTEs could be
produced before the error they were related to.
This was bad for consumers like Xcode, which associate NOTEs with the
last error or warning diagnostic.
This collates these notes using a diagnostic transaction and only
outputs the errors if something goes wrong.
With the introduction of special decl names, `Identifier getName()` on
`ValueDecl` will be removed and pushed down to nominal declarations
whose name is guaranteed not to be special. Prepare for this by calling
to `DeclBaseName getBaseName()` instead where appropriate.
Now that preCheckExpression() can handle more cases, we can
eliminate a special case where sometimes we would make
DeclRefExprs instead of TypeExprs for references to generic
types.
Following feedback in https://github.com/apple/swift/pull/9758:
* Use a struct type for the result of hasValidCodingKeysEnum
* Use an enum type for the result of
* Skip fetching a canonical type before calling getAnyNominal()
(getAnyNominal() looks through sugar already)
* No need to cast to IterableDeclContext (or DeclContext, even)
Optional properties now get synthesized encodeIfPresent(...) and
decodeIfPresent(...) calls (to avoid encoding needless information, and
to be more accepting on input).
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.
* 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.
* 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
