* 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
Removes the _getBuiltinLogicValue intrinsic in favor of an open-coded
struct_extract in SIL. This removes Sema's last non-literal use of builtin
integer types and unblocks a bunch of cleanup.
This patch would be NFC, but it improves line information for conditional expression codegen.
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.
One of the two issues preventing us from running test/api-digester/stability-stdlib-abi.swift in swift-evolve tests has been fixed; delete the comment referencing it. There’s another bug that still needs to be fixed, so we still aren’t running this yet.
* Add swift_evolve feature and disable several tests
This change adds a swift_evolve feature to our lit configuration and uses it to mark several tests as unsupported by swift_evolve.
One of these—test/api-digester/stability-stdlib-abi.swift—is actually pretty bad; we would really like to have it. But the digester has known issues exposed by swift-evolve.
* Remove order dependency in another test
* Tweaks from Jordan’s review
* Distinguish between tests which are intentionally unsupported and temporarily disabled.
* Add an explanation for one unsupproted test.
* Code nitpick.
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.
• Convert _AbstractStringStorage to a protocol, and the free functions used to deduplicate implementations to extensions on that protocol.
• Move 'start' into the abstract type and use that to simplify some code
• Move the ASCII fast path for length into UTF16View.
• Add a weirder but faster way to check which (if any) of our NSString subclasses a given object is, and adopt it
This option access a file that lists protocol names that are 'whitelisted' for getting new protocol requirements.
This allows the SDK checker to avoid flagging protocol method additions for protocols that we know are not intended
for user classes to conform to.
LibraryEvolution.rst stipulates that adding or removing 'weak',
'unowned' and 'unowned(unsafe)' is a resilient change if the type
is resilient. This means we should not mangle these attributes as
part of the accessor declaration.
We want to make sure we are consistent when printing accessors.
@jrose-apple and I landed on the following table for disambiguating all
the possible combinations of accessors:
\### Computed Properties
| Semantics | Syntax |
|------------|------------------------|
| Read-only | var x: T { get } |
| Read-write | var x: T { get set } |
\### Stored Properties
| Semantics | Syntax |
|--------------------------|-------------------------------------|
| Immutable | let x: T |
| Mutable (trivial setter) | var x: T |
| Mutable (custom setter) | @_hasStorage var x: T { get set } |
| Private(set) | @_hasStorage var x: T { get } |
This first commit enables printing @_hasStorage outside of SIL mode.
