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.
We missed a few NSKeyedUnarchiver methods during our original renaming
for Swift — some of these methods still take NSData when they can take
Data. We can add Data variants which bridge to NSData to fix this in a
backwards-compatible way.
This is consistent with imported error codes, which are always
Hashable. URLError.Code was also Hashable in Swift 3.1 by virtue of
being defined as an enum; the change to a struct broke that.
rdar://problem/32066434
Logs a warning the first time a problematic class is archived or
unarchived. We expect people to actually fix these issues, so the
performance of the warning isn't too important.
Sample output:
[timestamp] Attempting to archive Swift class '_Test.Outer.ArchivedThenUnarchived', which does not have a stable runtime name.
[timestamp] Use the 'objc' attribute to ensure that the runtime name will not change: "@objc(_TtCC5_Test5Outer22ArchivedThenUnarchived)"
[timestamp] If there are no existing archives containing this class, you can choose a unique, prefixed name instead: "@objc(ABCArchivedThenUnarchived)"
Finishes rdar://problem/32414508
SingleValueDecondingContainers in JSON and Plist previously held the
assertion that attempting to decode an array or dictionary from them
was a type mismatch (since those represented unkeyed and keyed
containers, respectively). This assertion is no longer true, though,
since encode<T : Encodable>(_:) and decode<T : Decodable>(_:) allow
you to do just that.
This lifts the assertion and adds unit tests to both implementations to
ensure this works. (Addresses https://bugs.swift.org/browse/SR-5089)
This function checks if a mangled class name is going to be written into an NSArchive.
If yes, a warning should be printed and the return value should indicate that.
TODO: print the actual warning
rdar://problem/32414508
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
