Newly internal declarations include Hasher._seed and the integer overloads of Hasher._combine(_:), as well as _SipHash13 and _SipHash24.
Unify the interfaces of these SipHash testing structs with Hasher. Update SipHash test to cover Hasher, too.
Add @usableFromInline to all newly internal stuff. In addition to its normal use, it also enables white box testing; compile tests that need to use these declarations with -disable-access-control.
As noted in the proposal’s revision, this allows us to get rid of finalization checks, improves API robustness, and paves the way for making Hasher move-only in the future.
This implements the new last(where:), and lastIndex(of/where:) methods as
extensions on `BidirectionalCollection`, which partially implements SE-204.
The protocol requirements for `Sequence` and `Collection` as described
in the proposal need to wait until there's a solution for picking up the
specialized versions in types that conditionally conform to `BidirectionalCollection`.
Unicode Kelvin sign normalizes to ASCII 'K', but our comparison logic
didn't handle this situation when the other side was single-byte all
ASCII. Fall back to the slow comparison path if the point of
difference between an all-ASCII string and a UTF-16 string falls on
such a non-ASCII-yet-normalizes-to-ASCII scalar (rare).
Update ErrorType.swift
Example on IntParsingError should have Character as associated value type not String.
Also updated sample code to use c rather than s
This property is too specific in that it forces a particular normalization; let's not expose it this way, but instead in the future with a full normalization API.
The compiler can synthesize these, but it doesn't mark them
@inlinable, since in the general case they're just a "default"
implementation and not "the only implementation forever". But for a
two-element enum that's based on a part of IEEE 754, it's probably
safe to assume this is the only implementation forever, and that
can be important for performance.
https://bugs.swift.org/browse/SR-7094
Use begin_unpaired_access [no_nested_conflict] for
Builtin.performInstantaneousReadAccess. This can't be optimized away
and is the proper marker to use when the access scope is unknown.
Drop the requirement that
_semantics("optimize.sil.preserve_exclusivity") be @inline(never). We
actually want theses inlined into user code. Verify that the
@_semantic functions are not inlined or otherwise tampered with prior
to serialization.
Make *no* change to propagate @inline(__always) into LLVM. This no longer has
any relationship to this PR and can be investigated seperately.
Add dynamic enforcement of exclusive access when a KeyPath directly accesses a final
stored property on an instance of a class. For read-only projections, this begins and ends
the access immediately. For mutable projections, this uses the ClassHolder to perform
a long-term access that lasts as long as the lifetime of the ClassHolder.
rdar://problem/31972680
- String hashing is not inlinable, so it can use _Hasher._core operations directly. Remove custom buffering.
- Speed up ASCII hashing by as much as 5.5x by feeding the storage buffer directly into hasher in a single go.
- For other strings, just feed the UTF-8 encoding of the normalized string to the hasher; don't switch to UTF-16 at the first non-ASCII scalar. (Doing that would make the hash encoding of some string sequences ambiguous, leading to artificial collisions.)
- Add a single unconditional terminator byte, 0xFF. It's not a valid UTF-8 code unit, so it won't ever occur within a normalized string encoding.
Since the functions produce pointers with tightly-scoped lifetimes there's no formal reason these have to only work on `inout` things. Now that arguments can be +0, we can even do this without copying values that we already have at +0.
_SwiftNewtypeWrapper forwarded hashValue to its rawValue, but it failed to do the same for _hash(into:), which resulted in the wrapper struct having subtly different hashing than the raw value.
This violated an implicit invariant when dictionaries/sets of such types were bridged to Objective-C through AnyHashable, leading to nondeterministic but frequent crashes.
rdar://problem/39398060
- Make RawRepresentable Codable abstracts distinguishable
- Make the UnboundedRange example a little more user friendly
- Correct the RangeReplaceableCollection example description
- Revise CaseIterable discussion
Avoid describing the exact algorithm that these collections use to allocate storage. (It is a private implementation detail that we want to be able to change.)
rdar://problem/36619317
