We want to be able to potentially introduce new metadata kinds in future Swift compilers, so a runtime ought to be able to degrade gracefully in the face of metadata kinds it doesn't know about. Remove attempts to exhaustively switch over metadata kinds and instead treat unknown metadata kinds as opaque.
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
Use AccessedStorageAnalysis to find access markers with no nested conflicts.
This optimization analyzes the scope of each access to determine
whether it contains a potentially conflicting access. If not, then it
can be demoted to an instantaneous check, which still catches
conflicts on any enclosing outer scope.
This removes up to half of the runtime calls associated with
exclusivity checking.
This got exposed due to the change to use witness tables as part of the
metadata cache key.
The Swift._ConcreteHashableBox<MinimalHashableValue> metadata created as
part of:
AnyHashable(MinimalHashableValue(1))
and
AnyHashable(_bridgeAnythingToObjectiveC(MinimalHashableValue(1)) as! NSObject)
Would not be uniqued to the same metadata because the witness table of
NSObject that we queried before that change was not equal to the witness
table of MinimalHashableValue.
This is tested by the AnyHashable.swift.gyb test case.
rdar://24958043
- Add swift_getForeignWitnessTable to unique non-unique foreign type
witness tables
- IRGen: Call the foreign witness uniquing runtime function
rdar://24958043
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.
