Tests using a mock SDK can't load the stdlib of the normal SDK (or the
just-built one) with the recent changes. Use `-parse-stdlib` in those
tests to prevent loading the stdlib implicitly.
The type `Hasher._Core` is `@frozen` but its stored properties are `private`, which currently makes them show up in api-digester ABI reports, leading to failures like this one:
```
+Var Hasher._Core._buffer has mangled name changing from 'Swift.Hasher._Core.(_buffer in _A19879A32F7D08A6DD54BABBA00BBA0C) : Swift.Hasher._TailBuffer' to 'Swift.Hasher._Core.(_buffer in _16630011A164FCBB1F12E5E0A3A7C863) : Swift.Hasher._TailBuffer'
```
These names aren't ABI impacting, so this checker probably should ignore their name changes. (The property names do appear in the .swiftinterface files, but IIUC the only their type and ordering matters.)
These ever-changing unstable ids make it impossible to add an entry to the expectation list that would allow these tests to pass. Work around this issue by postprocessing the reports to replace the unstable parts with the constant string `#UNSTABLE ID#`.
rdar://82552099
Moving generic constraint from extension to its member or vice versa may change the mangled name
of the member without changing the generic signature, thus introducing ABI breakages. This change
teaches the ABI checker to diagnose USR (mangled name) changes to cover such cases.
rdar://78276290
Before this change, the ABI checker didn't complain about missing @available
attributes on new APIs if the enclosing scopes of new APIs have
availability information. Instead, we should require explicit @available attributes
for new APIs to prevent them inheriting wrong availability information from a
preexisting scope.
rdar://81719628
These were defined for both FixedWidthInteger and FixedWidthInteger & SignedInteger for source compatibility with Swift 3; the latter set probably should have been removed when we stabilized the ABI, but were not. We can't easily remove them entirely (because we need them for ABI stability now), but we can mark them unavailable so that the typechecker doesn't have to consider them..
* 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.
