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
Previously we could only handle symbolic references at the
top level, but this is insufficient; for example, you can
have a nested type X.Y where X is defined in the current
translation unit and Y is defined in an extension of X in
a different translation unit. In this case, X.Y mangles as
a tree where the child contains a symbolic reference to X.
Handle this by adding a new form of Demangle::mangleNode()
which takes a callback for resolving symbolic references.
Fixes <rdar://problem/39613190>.
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
This is safe to do with hash(into:), because random hash collisions can be eliminated with awesome certainty by trying a number of different hash seeds. (Unless there is a weakness in SipHash.)
In some cases, we intentionally want hashing to produce looser equivalency classes than equality — to let those cases keep working, add an optional hashEqualityOracle parameter.
Review usages of checkHashable and add hash oracles as needed.
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
StdlibUnittest uses gyb to avoid duplicating many source-context
arguments. However, this means that any test that wishes to add new
expect helpers has to also be gybbed. Given that this structure hasn't
changed in years, and we should have a real language support
eventually, de-gyb it.
- 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.
A Decimal value with _length 0 and _isNegative set to 1 is interpreted as a NaN. The 'negate()' function however, flipped the _isNegative flag without regard for the _length 0 case. This meant that -0 would become NaN. The fix checks for the _length 0 special case. In NSDecimalSubtract() the same check was performed. Since this now happens in negate(), it is removed from the NSDecimalSubtract() function.
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
The quad precision support in visual studio does not support
the operations which clang will sometimes lower. These currently
generate code using GNU extensions. Add additional stubs for math
routines on Windows. This allows the standard library to build in
debug mode.
When building on Linux, the definition of `swift_snprintf_l` would cause
an unused function warning. Expand the scope of the preprocessor guard
to encompass the function for the single use. This avoids the unused
function warning.
Some of the previously used stubs are no longer needed in newer releases
of the Android API. Android L and Android O provide the functions in
their associated versions of bionic. This is needed to build against a
newer version of the SDK.
The returned type `std::streamoff` on Windows x64 is a `long long`
rather than `int`. This results in a 64-to-32 bit shortening of the
value. Use the appropriate type to avoid the truncation.
`strlen` returns a unsigned value, but `std::streamoff` is an signed
value. Explicitly cast the value to avoid the warning about the
implicit signed conversion.
Move the duplicated compiler-rt support routines into its own source
file. This will need to be expanded for Windows. As on Linux, there
are certain builtin routines which are not available from the standard
runtime and need to be augmented for now.
We were misinterpreting the protocol conformances as the protocol sections. It
is interesting that this never was caught in any of the runs on the build bots
nor was it caught during the normal execution of code.
Merge SR-3131 fix:
For each floating-point type, there is a range of integers which
can be exactly represented in that type. Adjust the formatting
logic so that we use decimal format for integers within this
range, exponential format for numbers outside of this range.
For example, Double has a 53-bit significand so can exactly
represent every integer from `-(2^53)...(2^53)`. With this
change, we now use decimal format for these integers and
exponential format for values outside of this range. This is
a relatively small change from the previous logic -- we've
basically just moved the cutoff from 10^15 to 2^53 (about 10^17).
The decision for using exponential format for small numbers is
not changed.
- Make RawRepresentable Codable abstracts distinguishable
- Make the UnboundedRange example a little more user friendly
- Correct the RangeReplaceableCollection example description
- Revise CaseIterable discussion
