* Break ambiguity for types conforming to both UEC and SVEC
If an encoding container conforms to _both_ UEC and SVEC and does not
itself implement support for [U]Int128, there is an ambiguity between
the two default implementations. Add additional defaults defined on
the intersection of the protocols to resolve this.
* Update abi tests for new ambiguity breakers.
Make both Error and CodingKey conform to ConcurrentValue, so that
thrown errors always conform to ConcurrentValue. Downgrade (to
warnings) and ConcurrentValue-related diagnostics that are triggered
by this change in existing Error and CodingKey-conforming types to
reduce the impact on source compatibility.
Introduce checking of ConcurrentValue conformances:
- For structs, check that each stored property conforms to ConcurrentValue
- For enums, check that each associated value conforms to ConcurrentValue
- For classes, check that each stored property is immutable and conforms
to ConcurrentValue
Because all of the stored properties / associated values need to be
visible for this check to work, limit ConcurrentValue conformances to
be in the same source file as the type definition.
This checking can be disabled by conforming to a new marker protocol,
UnsafeConcurrentValue, that refines ConcurrentValue.
UnsafeConcurrentValue otherwise his no specific meaning. This allows
both "I know what I'm doing" for types that manage concurrent access
themselves as well as enabling retroactive conformance, both of which
are fundamentally unsafe but also quite necessary.
The bulk of this change ended up being to the standard library, because
all conformances of standard library types to the ConcurrentValue
protocol needed to be sunk down into the standard library so they
would benefit from the checking above. There were numerous little
mistakes in the initial pass through the stsandard library types that
have now been corrected.
Due to an unstable (and undesirable) calling convention in the LLVM layer for x86, I had previously marked Float16 unconditionally unavailable on macOS. My hope was that Intel would stabilize the calling convention and we could make it available on both macOS platforms at the same time. Unfortunately, that hasn't happened, and we want to make the type available for macOS/arm users.
So, I am making the availability mirror Float80--the type will be unavailable for macOS on x86_64, and available on all other platforms (the other x86 platforms don't have a binary-stability guarantee to worry about). This isn't ideal. In particular, if/when the calling conventions for Float16 stabilize in LLVM, we would want to make the type available, but it would then have _different_ availability for different architectures of macOS, which the current availability system is not well-equipped to handle (it's possible, but not very ergonomic). Nonetheless, this seems like the best option.
The good news is that because the full API is already built in Swift (and simply marked unavailable), we can simply add macOS 11.0 availability for these API and it will work.
LLVM doesn't have a stable ABI for Float16 on x86 yet; we're working with Intel to get that fixed, but we don't want to make the type available on macOS until a stable ABI is actually available, because we'd break binaries compiled before any calling convention changes if we do.
In particular, types generic on the CodingKey produce a lot of runtime metadata.
Reducing the number of such types should help with some of the reported memory
bloat from Codable.
Based on a suggestion of @jckarter
Resolves rdar://62620208
Array, Set, Dictionary, and Optional all provide unconditional conformances
to Encodable & Decodable that dynamically check whether their type arguments
are Encodable/Decodable. Now that we have conditional conformances, make
these unconditional conformances properly conditional, removing all of
the Swift 4-era type-erasure hacks.
Fixes rdar://problem/34989162.
As a temporary workaround for SR-5206, certain Foundation types which had custom behavior in JSONEncoder and JSONDecoder were granted special knowledge of those types internally in order to preserve strategies on encode/decode.
This replaces that special knowledge with a more general-purpose fix that works for all types and all encoders/decoders.
- Revisions to unsafeDowncast and withVaList
- Fix the Int64/UInt64 discussion
- Buffer pointer revisions
- Fix Optional example to use new integer methods
- Revise and correct some UnsafeRawBufferPointer docs
- Fix symmetricDifference examples
- Fix wording in FloatingPoint.nextDown
- Update ImplicitlyUnwrappedOptional
- Clarify elementsEqual
- Minor integer doc fixes
- Comment for _AppendKeyPath
- Clarification re collection indices
- Revise RangeExpression.relative(to:)
- Codable revisions
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]`.
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 encodeNil(forKey:)/encodeNil() for keyed/unkeyed encoding
containers
* Add decodeNil(forKey:)/decodeNil() for keyed/unkeyed decoding
containers
* Give default implementation of decodeIfPresent(forKey:)/
decodeIfPresent(_:) on keyed/unkeyed decoding containers instead of
decode(forKey:)/decode(_:)
* Expose all encode/decode methods on keyed encoding & decoding
containers to allow overriding default methods (which were previously
not forwarding)
