@effects is too low a level, and not meant for general usage outside
the standard library. Therefore it deserves to be underscored like
other such attributes.
Simplify String.Index by sinking transcoded offsets into the .utf8
variant. This is in preparation for a more resilient index type
capable of supporting existential string indices.
The real work is done in checkDynamicCastFromOptional. This code tried to unwrap the source and returned the payload on success. It only did this once, so a type like Optional<Optional<Int>> would come out as Optional<Int> and then a cast to Int would fail.
This change makes checkDynamicCastFromOptional recursive, which makes it unwrap as many levels of Optional as it encounters.
Fixes rdar://problem/40171034 and SR-7664.
This fixes a problem where error bridging didn't work in stripped executables using the static versions of the Swift libraries. ErrorObject.mm looks up some symbols with dlsym, but stripping makes it so it can't find those. This change makes a separate set of symbols explicitly made for ErrorObject.mm to look up, and marks them as dynamically referenced so stripping won't remove them. Longer term, we'd like a better solution for looking up these symbols, but this will do for now.
rdar://problem/39810532
Extract slow paths into non-inlinable functions so that fast-paths can
be faster and we don't pay the large code bloat for the Unicode
parsers.
Some tests proactively extended to highlight UTF8View of multiple
kinds of Strings.
That is, if there's a problem with a witness, and the witness comes
from a different extension from the conformance (or the original type,
when the conformance is on an extension), put the main diagnostic on
the conformance, with a note on the witness. This involves some
shuffling and rephrasing of existing diagnostics too.
There's a few reasons for this change:
- More context. It may not be obvious why a declaration in file
A.swift needs to be marked 'public' if you can't see the conformance
in B.swift.
- Better locations for imported declarations. If you're checking a
conformance in a source file but the witness came from an imported
module, it's better to put the diagnostic on the part you have
control over. (This is especially true in Xcode, which can't display
diagnostics on imported declarations in the source editor.)
- Plays better with batch mode. Without this change, you can have
diagnostics being reported in file A.swift that are tied to a
conformance declared in file B.swift. Of course the contents of
A.swift also affect the diagnostic, but compiling A.swift on its
own wouldn't produce the diagnostic, and so putting it there is
problematic.
The change does in some cases make for a worse user experience,
though; if you just want to apply the changes and move on, the main
diagnostic isn't in the "right place". It's the note that has the info
and possible fix-it. It's also a slightly more complicated
implementation.
On Darwin (and most other OSes), subnormal support is turned off for armv7, which causes these tests to fail. Longer-term, instead of gating this on architecture we may want to be able to query if subnormals are supported for a BinaryFloatingPoint type, and then we could key off of that instead.
Non-tagged NSStrings carry identity separate from their
value. Continue to bridge them lazily, even if they could fit in small
form, to respect this and avoid potential information loss.
Temporarily disable invariant that all natives strings that could be
small, are.
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).
The "not native" bit in a BridgeObject is important, because it tells
us when we need to go through the Objective-C -retain method
vs. swift_retain. Losing the bit means that swift_retain() will stomp
on some memory within an Objective-C object, thinking its the inline
reference count.
Co-debugged with Arnold, who then found where this bit was getting dropped.
Fixes rdar://problem/39629937.
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>.
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.
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.
Due to SR-7124, some float literals are inconsistently handled
across architectures. That's a problem for a test which is
trying to verify that certain exact floating-point values are
formatted in specific ways.
Fortunately, the run-time float parsing does not have this
problem, so I've changed this test to make sparing use of
run-time parsing (`Float("1.234")`) instead of compile-time
parsing (`1.234 as Float`).
This is admittedly slower, but the test isn't particularly
performance critical, and I don't want to use a hex literal
here since I feel that would make the test case harder to
understand.
NaNs are mangled in various ways on various platforms. Some
of the fun possibilities:
* sign bits can be cleared
* payloads get zeroed
* NaNs get forced to quiet
* Merely passing a value into a function can trigger these behaviors
* Trivial changes to the generated assembly can change this
This makes it very hard to validate the printing of NaN
details, since we can't be certain what value the formatter
actually saw.
So now I only do exact checks of the NaN formatter on x86_64,
which has pretty well-understood NaN support. On all other
platforms, I just check that the debugDescription output
has the expected format:
```
-?s?nan(\(0x[0-9a-f]+\))?
```
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.
This was an oversight from PR #15474. Most of the Float80
tests were correctly compiled only on `!Windows && (x86 || i386)`
but I failed to mark some Float80 test data.
Fixes: Radar 39246292
