* Casting from AnyHashable to AnyHashable should never create another wrapper
This adds a conformance for _HasCustomAnyHashableRepresentation to
AnyHashable that simply returns self. This ensures that anytime
you try to create a new AnyHashable wrapper for an existing
AnyHashable, you just get back the original.
Resolves rdar://75180619
* Move the `Struct AnyHashable` change to `without-asserts` list
As suggested by @lorentey
Make both Error and CodingKey conform to ConcurrentValue, so that
thrown errors always conform to ConcurrentValue. Downgrade (to
warnings) and ConcurrentValue-related diagnostics that are triggered
by this change in existing Error and CodingKey-conforming types to
reduce the impact on source compatibility.
When referring to an actor-isolated declaration from outside of the
actor, ensure that the types involved conform to the `ConcurrentValue`
protocol. Otherwise, produce a diagnostic stating that it is unsafe to
pass such types across actors.
Apply the same rule to local captures within concurrent code.
This is only relevant for assert builds of the library.
Fixes an undefined symbol error if an executable, compiled with an assert build of the stdlib, is back deployed on a platform which does not support lazy symbol binding.
rdar://problem/71201102
The error messages emitted from the ABI checker are mostly explanations of breakages. We should
explicitly mention why they are emitted to differentiate them from other compiler diagnostics.
rdar://68864860
When the checker found a breakage listed in the user-specified list,
the breage should be consumed internally without failing the check.
rdar://68086477
Removing or updating @_alwaysEmitIntoClient functions are never ABI-breaking, thus
we should exclude them from the symbol set for ABI stability checking.
rdar://67883661
The standard library on non-Intel targets get compared to the baseline
from the Intel targets which is not guaranteed to be identical. Mark
the checks as expected failures on non-x86_64 targets. Although this is
entirely unsatisfying, it allows progress in the short term.
Most of this is enabled by an upstream change to generalize the tests
for the api-digester to properly handle all targets. The primary change
here is to account for the Swift-level ABI differences for the standard
library between Apple Silicon macOS and Intel macOS. Specifically, anything
related to Float80 will be removed from the standard library on Apple Silicon
macOS, so account for the differences.
Most of the changes fall into a few categories:
* Replace explicit "x86_64" with %target-cpu in lit tests
* Cope with architecture differences in IR/asm/etc. macOS-specific tests
Previously inherited constructors would be skipped from added in member list, depending on the order of request evaluator calls.
This was a regression compared to swift 5.2
Client code can't override or subclass a `public` declaration already, so although the ABI differs, the API is the same
whether something is `final` or not.
The API digester tests were being run only for macOS, mainly
because they were not using %target-swift consistently. Lift
the unnecessary restriction so we run these tests more widely.
Using a directory instead of an exact file name for the generated
baseline allows the tool to use target triple as file name, which is
expected by the diagnostic phase.
