By calling through to swift_reportToDebugger, Xcode can pick up the
NSKeyedArchiver/Unarchiver issues with Swift classes and display them
in the Issues Navigator. This increases the probability that they'll
be seen and acted upon.
This is not a fully-general interface yet, please do not start hooking
random things up to it. Especially if you're working on something that
doesn't ship with Xcode itself. :-)
rdar://problem/32900735
{JSON,Plist}{Encoder,Decoder} had overlapping accesses which were supposed to be mutually exclusive in their `with(pushedKey:)` methods.
Removes those methods and the overlapping accesses.
I failed to merge the upstream changes to swift-corelibs-foundation at the same
time as I merged that #9806, and it broke on linux. Going to get it right this
time.
One of the limitations of not having conditional conformance at the
moment is that the implementation of `init(from:)` and `encode(to:)` on
types which require it is that failure to cast dependent types to
`Encodable` or `Decodable` is a runtime failure. There is no way to
statically guarantee that the wrapped type is `Encodable` or
`Decodable`.
As such, in those implementations, at best we can directly call
`(element as! Encodable).encode(to: encoder)`, or similar. However, this
encodes the element directly into an encoder, without giving the encoder
a chance to intercept the type. This is problematic for `JSONEncoder`
because it cannot apply a strategy if it doesn't get to intercept the
type.
This gives a temporary workaround for JSON strategies because of
internal Foundation knowledge.
For the benefit of unkeyed containers, coding paths currently contain optional `CodingKey`s — unkeyed containers are allowed to report a `nil` key in a path. However, this is unhelpful for debugging purposes, or inspecting the coding path for context, since any unkeyed container simply reports `nil`, whether it’s at index 1 or 1000.
Now all containers are required to report a non-optional CodingKey for their segment of the coding path, and coding paths are now exposed as `[CodingKey]`.
If JSONSerialization or PropertyListSerialization throw errors during encoding or decoding, the error should be exposed as an EncodingError or DecodingError
CustomNSError briding only works when the CustomNSError conformance is in the same module as the original error declaration. We need to sink these down into the standard library.
* Add deferredToData strategy on encode and decode
* Rename base64{Encode,Decode} to base64 (missed this in previous fixes)
* Add unit test to confirm behavior
* Update {JSON,PropertyList}Decoder to allow superDecoder()s to wrap
null value so current implementations of collections can decode
contained objects from nil
To make it slightly easier to tell at a glance if a method is
implemented as part of API (public/open), shared implementation detail
(fileprivate), or implementation detail meaningful only to a given type
(private).
Allow JSONEncoder/JSONDecoder to intercept Decimal values so they get
a numeric representation in JSON (instead of their default keyed
implementation).
On encode, we previously treated every container request as a push;
instead, we should allow the same container type to be requested
multiple times so a class can pass its Encoder directly to its
superclass if it needs to.
The unarchiveTopLevelObjectWithData which returns Any? (instead of
AnyObject?) was added in Swift 4 and has only shipped in the betas so
far. Instead of adding new overloads which take different types, we
should just fix this one and call it a day.
