We started to diagnose new APIs such as the missing of @available attributes. This diverges
the expected change lists for builds with/without assertions enabled because some stdlib
symbols are included only when asserts are enabled. We start to require
asserts here to make sure the test doesn't fail on no-assertion settings.
New ABIs should have an @available attribute to describe the introducing
version. This patch teaches the tool to diagnose its missing.
Decls with @_AlwaysEmitIntoClient are excluded from the blaming lists since
they are essentially available all the time.
rdar://51089418
External type declarations are synthesized to incorporate members in extensions to types
of external modules. In diagnostics, we should use 'extension' instead of 'struct/class'
for these decls to avoid confusion.
To incorporate extensions to types from other modules, the tool sometimes needs
to pull type declaration from external modules even though these modules
are not under checking. We need a flag to explicitly mark such case.
SDK conformance nodes include only protocol
`name` and `printedName`, both are demangled.
USR field of the protocol type is added, to be able
to uniquely identify conformances.
This implements the protocols and static functions proposed in SE-0246, plus some initial test coverage. It also has some rough accompanying cleanup of tgmath. It does not include the globals (on scalars or SIMD types) nor does it deprecate much in tgmath.h.
* Revert "Merge pull request #23791 from compnerd/you-know-nothing-clang"
This reverts commit 5150981150, reversing
changes made to 8fc305c03e.
* Revert "Merge pull request #23780 from compnerd/math-is-terrible"
This reverts commit 2d7fedd25f, reversing
changes made to 0205150b8f.
* Revert "Merge pull request #23140 from stephentyrone/mafs"
This reverts commit 777750dc51, reversing
changes made to 0c8920e747.
This commit implements SE-0246, by adding conformance to Real to the Float, CGFloat, Double, and Float80 types, implemented either in terms of the system's C math library, existing standard library functionality, or LLVM intrinsics. It includes basic test coverage for these new functions, and deprecates and obsoletes *some* existing functionality in the Platform overlay. We still need to make a decision about how to handle the remaining "tgmath" functions, because obsoleting them is technically a source-breaking change (if users have unqualified names like "exp(1)", it's fine, but it would break users who have used qualified names like "Darwin.exp(1)".)
ABI placeholders are decls with attribute '@available(macOS 9999, iOS
9999, tvOS 9999, watchOS 9999, *)'. The diagnostics phase could be
forgiving for ABI breakages on these decls since they are added
recently. This patch adds a new flag to the json file indicating whether
a declaration or a conformance is an ABI placeholder. The checking of
placeholder is transitive, meaning a decl is an ABI placeholder if its
decl context is one.
rdar://49502365
Protocol requirements may not necessarily add new entries to the witness table if
it's inherited from super protocol. This patch teaches the json dump to
include a flag indicating whether a protocol requirement requires new
witness table entry and diagnoses the change of such flag as ABI
breakages.
rdar://47657204
Otherwise we can get in trouble when a local type is named, say,
'Sequence'.
Also contains test updates and a fix for Harlan's previous commit,
which actually affects all typealiases, not just those in the Builtin
module.
This avoids us having to pattern match every source file which should
help speed up the CMake generation. A secondary optimization is
possible with CMake 3.14 which has the ability to remove the last
extension component without having to resort to regular expressions. It
also helps easily identify the GYB'ed sources.
Sorting of DeclContext-local protocols and conformances shouldn't ever
be necessary, because the underlying data structures that produce
these lists should be deterministic. Sorting can hide any
non-determinism, so stop doing it and we can address the underlying
nondeterminism.
Upon seeing an extension for a type outside the current module, the digester
creates a dummy type node and puts all the extensions’ members and conformances
in that type. This allows us to track new API endpoints that are retroactively
added.
Unfortunately, if there are no public members/conformances (only internal or
private ones), the type itself ends up in the SDK dump without any public
children. This causes an issue when you dump the SDK from a parseable
interface, where the internal extension was not printed.
Without this change, SILGen will crash when compiling a use of the
derived protocol's requirement: it will instead attempt to use
the base protocol's requirement, but the code will have been
type-checked incorrectly for that.
This has a potential for source-compatibility impact if anyone's
using explicit override checking for their protocol requirements:
reasonable idioms like overriding a mutating requirement with a
non-mutating one will no longer count as an override. However,
this is arguably a bug-fix, because the current designed intent
of protocol override checking is to not allow any differences in
type, even "covariant" changes like making a mutating requirement
non-mutating. Moreover, we believe explicit override checking in
protocols is quite uncommon, so the overall compatibility impact
will be low.
This also has a potential for ABI impact whenever something that
was once an override becomes a non-override and thus requires a
new entry. It might require a contrived test case to demonstrate
that while using the derived entry, but it's quite possible to
imagine a situation where the derived entry is not used directly
but nonetheless has ABI impact.
Furthermore, as part of developing this patch (earlier versions of
which used stricter rules in places), I discovered a number of
places where the standard library was unintentionally introducing
a new requirement in a derived protocol when it intended only to
guide associated type deduction. Fixing that (as I have in this
patch) *definitely* has ABI impact.
* Make SIMD types codable. We're considering this a bugfix.
This is a very tiny ABI change, in that user-defined SIMD types compiled with an earlier version of 5.0 will be missing the necessary conformance to Codable. Discussed with Ben, and we're OK with this because we don't think there are such types yet, and it can be fixed with a recompile.
* Add basic tests
For lazy vars, we need to make public the top-level entry point, and the fact
that the lazy storage contributes to the layout of a type (if it’s fixed
layout, or if the type is not resilient.) We also shouldn’t ever print `lazy`
in a parseable interface.
Since we need to parse these identifiers, give them a new name,
`$__lazy_storage_$_{propname}`, which is parseable only in parseable interfaces
so it doesn’t conflict with other properties.
Old Swift and new Swift runtimes and overlays need to coexist in the same process. This means there must not be any classes which have the same ObjC runtime name in old and new, because the ObjC runtime doesn't like name collisions.
When possible without breaking source compatibility, classes were renamed in Swift, which results in a different ObjC name.
Public classes were renamed only on the ObjC side using the @_objcRuntimeName attribute.
This is similar to the work done in pull request #19295. That only renamed @objc classes. This renames all of the others, since even pure Swift classes still get an ObjC name.
rdar://problem/46646438
In anticipation of potential future HW features, e.g. armv8.5 memory
tagging, only use the high 4 bytes as discriminator bits in
_BridgeObject rather than the top 8 bits. Utilize two perf flags to
cover this instead. This requires shifting around a fair amount of
internal complexity.
Remove Discriminator, Flags, etc., abstractions from
StringObject. These cause code divergence between 32-bit and 64-bit
ABI, complicate ABI changes, and otherwise contribute to bloat.
The standard library has two versions of the `abs(_:)` function:
```
func abs<T : SignedNumeric>(_ x: T) -> T where T.Magnitude == T
func abs<T : SignedNumeric & Comparable>(_ x: T) -> T
```
The first is more specialized than the second because `T.Magnitude` is
known to conform to `Comparable`. Indeed, it’s a more specialized
implementation that returns `magnitude`.
However, this overload behaves oddly: in the expression `abs(-8)`, the type
checker will pick the first overload because it is more specialized. That’s
a general guiding principle for overloading: pick the most specialized
overload that works.
However, to select that overload, it needs to pick a type for the literal
“8” for which that overload works, and it chooses `Double`. The “obvious”
answer, `Int`, doesn’t work because `Int.Magnitude == UInt`.
There is a conflict between the two rules, here: we prefer more-specialized
overloads (but we’ll fall back to less-specialized if those don’t work) and we prefer to use `Int` for integer literals (but we’ll fall back to `Double` if it doesn’t work). We have a few options from a type-checker
perspective:
1. Consider the more-specialized-function rule to be more important
2. Consider the integer-literals-prefer-`Int` rule to be more important
3. Call the result ambiguous and make the user annotate it
The type checker currently does #1, although at some point in the past it
did #2. Moving forward, #1 is a better choice because it prunes the number
of overloads that need to be considered: if the more-specialized overload
succeeds its type-check, the others need not be considered. It’s also
easier to reason about than the literal-scoring approach, because there can
be a direct definition for “more specialized than” that can be reasoned
about.
I think we should dodge the issue by removing the more-specialized version
of `abs(_:)`. Its use of `magnitude` seems unlikely to provide a
significant performance benefit, and the presence of overloading either
forces us to consider both overloads always (which is bad for type checker
performance) or accept the regression that `abs(-8)` is `Double`. Better
to eliminate the overloading and, if needed in the future, find a better
way to introduce the more-specialized implementation without it being a
separate signature.
Fixes rdar://problem/42345366.
Include some tuning and tweaking to reduce the constant factors
involved in string comparison. This yields considerable improvement on
our micro-benchmarks, and allows us to make less inlinable code and
have a smaller ABI surface area.
Adds more extensive testing of corner cases in our existing
fast-paths.
Defining a custom iterator for the UTF16View avoid some redundant
computation over the indexing model. This speeds up iteration by
around 40% on non-ASCII strings.
Implements SE-0229.
Also updates simd module types in the Apple SDKs to use the new types, and updates a couple tests to work with the new types and protocols.
