Properties of Codable types which are optional and excluded via the CodingKeys enum should not require an explicit nil assignment, since in all other cases, optional vars get a default value of nil.
* Make Decodable synthesis lazy again
* Remove side effects from assertions
* Assert on superclass failable initializers (and verify via a unit test)
* Fix space typo
* Remove more needless instances of single-element arrays
* Unambiguously refer to init() in unit tests
* Add failable superclass init tests and a test to ensure Decodable fails to be inherited when superclass synthesis fails
* Add tests for structs to ensure they receive no-argument initializers where appropriate
* 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 inherit from Codable classes inherit their Codable implementation (as opposed to synthesizing their own). In cases where they add their own storage, they will fail to inherit their superclass’s init(from:). In this case, we provide a diagnostic suggesting that init(from:) be overridden.
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.
Some types and members are synthesized by derived protocol conformances
(e.g. the CodingKeys member type or init(from:)/encode(to:) members
from Decodable/Encodable conformance) — however, they are not visible
in AST lookup if they have not been synthesized.
Exposes a LazyResolver callback for performing member synthesis where
relevant during qualified lookups to synthesize these members on demand
when needed.
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.
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
