Support demangling for types nested within some simple extension contexts.
Still does not support nested types within constrained extensions that
involve same-type constraints among generic parameters, nor
deeply-nested types in extensions. However, it fixes
rdar://problem/40071688.
Previously, swiftImageInspectionShared generated one specific library at
`lib/libswiftImageInspectionShared.a` for only the main arch and sdk.
Generic cross compilation and various changes to the build system to get
cross compilation to work will require swiftImageInspectionShared to
generate libraries at the proper subdirectory. Change the outputs to
agree with paths such as `lib/swift/linux/x86_64`
This hoists out the retain into Swift code from the casting runtime and along a
few paths in the runtime allows us to eliminate a dynamic retain release.
rdar://38196046
rdar://38771331
This is truly a consuming operation. This can be seen since we always would need
to retain the argument here. This makes guaranteed -> owned less transformation
effective. Instead represent it taking a +1 argument so that the retain happens
outside the builtin instead of inside the builtin.
This also allows me to remove an extra copy from dynamicCastValueToNSError
rdar://38771331
This collects a number of changes I've been testing over the
last month.
* Bug fix: The single-precision float formatter did not always
round the last digit even in cases where there were two
possible outputs that were otherwise equally good.
* Algorithm simplification: The condition for determining
whether to widen or narrow the interval was more complex than
necessary. I now simply widen the interval for all even
significands.
* Code simplification: The single-precision float formatter now uses fewer
64-bit features. This eliminated some 32-bit vs. 64-bit conditionals in
exchange for a minor loss of performance (~2%).
* Minor performance tweaks: Steve Canon pointed out a few places
where I could avoid some extraneous arithmetic.
I've also rewritten a lot of comments to try to make the exposition
clearer.
The earlier testing regime focused on testing from first
principles. For example, I verified accuracy by feeding the
result back into the C library `strtof`, `strtod`, etc. and
checking round-trip exactness. Unfortunately, this approach
requires many checks for each value, limiting test performance.
It's also difficult to validate last-digit rounding.
For this round of updates, I've instead compared the digit
decompositions to other popular algorithms:
* David M. Gay's gdtoa library is a robust and well-tested
implementation based on Dragon4. It supports all formats, but
is slow. (netlib.org/fp)
* Grisu3 supports Float and Double. It is fast but incomplete,
failing on about 1% of all inputs.
(github.com/google/double-conversion)
* Errol4 is fast and complete but only supports Double. The
repository includes an implementation of the enumeration
algorithm described in the Errol paper.
(github.com/marcandrysco/errol)
The exact tests varied by format:
* Float: SwiftDtoa now generates the exact same digits as gdtoa
for every single-precision Float.
* Double: Testing against Grisu3 (with fallback to Errol4 when
Grisu3 failed) greatly improved test performance. This
allowed me to test 100 trillion (10^14) randomly-selected
doubles in a reasonable amount of time. I also checked all
values generated by the Errol enumeration algorithm.
* Float80: I compared the Float80 output to the gdtoa library
because neither Grisu3 nor Errol4 yet supports 80-bit extended
precision. All values generated by the Errol enumeration
algorithm have been checked, as well as several billion
randomly-selected values.
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>.
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.
When building with assertions enabled, link the demangle tree dumper into
the runtime and remote mirrors libraries. This makes debugging demangling-related issues a whole lot easier.
