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.
De-genericize one axis of storage buffers to speed up compilation time
of stdlib and user code. Publish the rest as ABI, since we're out of
time to reevaluate the design.
The previous documentation was not accurate. It said that the length of
the error returned would be the length of the valid prefix. In case of
no valid prefix however the code will still return 1, contrary to the
documentation.
I fixed the documentation by adding the guarantee that the error length
will always be positive and removing the information about the valid
prefix as we might want to change the precise algorithm in the future.
In theory there could be a "fixed-layout" enum that's not exhaustive
but promises not to add any more cases with payloads, but we don't
need that distinction today.
(Note that @objc enums are still "fixed-layout" in the actual sense of
"having a compile-time known layout". There's just no special way to
spell that.)
This takes care of the standard library portion, but we need a new
BuiltinUTF16ExtendedGraphemeClusterLiteralConvertible protocol in order to
fully recover the performance of character literals.
Note that part of the character_literals.swift test is currently disabled. That
will need to be fixed before we can merge this work.
The best high-level APIs for decoding/transcoding are still under active
investigation. It's likely we want more views. Therefore, leave
de-underscored/public only the lowest-level APIs for now.
This is a follow-up fix for making struct constructors inline(__always) in
155db0a4bd: Let Character literals, which fit into 64 bits, be folded into a single integer constant.
and
d8f1caf4a6: Inline all the new low-level bits
If we decide that this structs should not have fixed layout we must re-evaluate the performance difference of not being able to inline
the struct constructors.
