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
