Lifetime indices are never necessary in Swift, they unnecessarily expose
implementation details, and they make lifetime annotations more error-prone,
since they may need to be updated if a function's parameter list changes.
The Swift Syntax parser also cannot handle lifetime annotations where the target
is an index. The main reason the C++ parser supports them is because it is also
used for SIL.
This change forces you to write ``@reparented` relationships
on an extension of a protocol, rather than on the protocol
itself.
The ProtocolConformance needs to be associated with some
GenericContext and IRGen expects it to be an ExtensionDecl.
That environment defines under what conditions the conformance
exists. We also need to define witnesses for the new parent's
requirements in an extension anyway, so it's a natural fit.
The previous workaround for this was kind of awful, as it'd
require searching all the protocol's extensions and "guess"
which extension they want to represent the conformance. While
we could try to synthesize an extension, there's two
challenges there:
1. Due to SuppressedAssociatedTypes, it's not so simple to
synthesize an unconstrained ExtensionDecl.
2. We currently rely on same-type requirements to pin the
associated types to particular witnesses of those requirements
in the extension. So it's not purely unconstrained! For example,
```
extension Seq: @reparented BorrowSeq where Iter == MyIter {}
```
The constraints that are disallowed (but not yet diagnosed)
are conditional conformance requirements, as the default
conformance for a reparenting cannot depend on those.
Thus, it's better that programmers to specify the extension.
A protocol that's been reparented declares it
by writing `@reparented` in its inheirtance clause
for each new parent. You can introduce a `@reparented`
parent to a pre-existing ABI-stable protocol's
inheritance hierarchy.
Only protocols declared to be `@reparentable` can be
used to reparent other protocols. Adding or removing
the `@reparentable` attribute is ABI-breaking, as it
effects the type metadata layout. Thus, reparentable
protocols must be born as such to use them with
protocols that are already ABI-stable.
This set of changes does not include the actual
implementation of ABI-stable reparenting.
As RedundantLoadElimination processing the loads in reverse control flow order, the replaced loads might accumulate quite a lot of users.
This happens if the are many loads from the same location in a row.
To void quadratic complexity in `uses.replaceAll`, we swap both load instructions and move the uses from the `existingLoad` (which usually has a small number of uses) to this load - and delete the `existingLoad`.
This came up in the Sema/large_int_array.swift.gyb test, which tests a 64k large Int array.
With this fix, the compile time gets down from 3 minutes to 5 seconds.
I also changed the test:
* run the compiler with the timeout script to detect build time regressions
* re-enabled the SIL verifier because the problem there is already fixed (https://github.com/swiftlang/swift/pull/86781)
* run the compiler with -O to also test the whole optimizer pipeline and not only the mandatory pipeline
* assigned the array to a real variable (instead of `_`) to not let the optimizer remove the whole array too early
* run the compiler with and without `-parse-as-library` because this makes a huge difference how the global array is being generated
Since after address lowering, `Borrow` can remain loadable with a known-
layout address-only referent, we need instructions that handle three
forms:
- borrow and referent are both loadable values
- borrow is a value, but referent is address-only
- borrow and referent are both address-only
This one is specific. Allow extensions to define public members to
package types implicitly exporting their memory layout when imported
non-publicly.
Enabling exportability checks for non-library-evolution by default as a
warning triggered marking such types as implicitly exported to clients.
This in turn enabled erroring on the extensions in clients when imported
non-publicly. This error would be source breaking and shouldn't be
required in such a context. We may even consider lifting this
restriction entierly, even for public types imported non-public.
Centralize the logic downgrading diagnostics to warning for newly
introduced exportability checks along with the one silencing the errors.
Update client sites to the new API and to uniformly apply the downgrade
to warning behavior.
Diagnostics about typealiases and conformances are now properly
downgraded to warnings if not opt-in.
Invite users of `@_implementationsOnly` imports from modules without
library-evolution to adopt `CheckImplementationOnly`. Use the existing warning
on the import statement. Adopting that feature reports unsafe references to
implementation-only imported types as errors and silences the warning on
the import.
Always enable checking for references to `@_implementationOnly` imports
even without library-evolution enabled but downgrade errors to warnings
by default. Clients should enable them as errors by adopting
`CheckImplementationOnly`.
This does not rename all the internal variables, functions, and types
whose names were based on the old syntax.
I think it adds new syntax support everywhere it's needed while
retaining enough of the old syntax support that early adopters will
see nice deprecation messages guiding them to the new syntax.
Some access control holes were unconditionally downgraded to warnings, and
others were conditional on Swift 6 language mode. Let's hang them off an
upcoming feature instead.
We don't have support for borrowing switch on Copyable types.
It is supported for ~Copyable types, but the return expression emission for borrow accessors is not yet implemented.
Diagnose instead of crashing the compiler.
In #65125 (and beyond) `matchTypes`, has logic to attempt to wrap an
incoming parameter in a tuple under certain conditions that might help
with type expansion.
In the case the incoming type was backed by a `var`, it would be wrapped
by an `LValueType` then be subsequently mis-diagnosed as not-a-tuple.
More details in #85924 , this this is also the cause of (and fix for)
#85837 as well...
Impact for an unknown property access was frequently higher than other options
on ambiguous selections, by 3 to 5 points, causing fix selections that were
farther away and frequently noted to be in accurate. This commit lowers the
impact to be in a similar range to other fixes and this causes property accesses
to be selected more proprotionaly.
In the existing test suite, this changed the diagnostic only in the case of
protocol composition, which was also discovered to be a flawed binding lookup.
Tests added for the property lookup, tests updated for protocol composition
(Including correcting a likely error in a test specification)
We now report properties referencing types imported from
implementation-only dependencies in non-library-evolution mode as the
memory layouts of structs and enums may be exposed to clients. Here we
exempt non-open classes from this check as clients hold pointers to
classes which hides the class internal memory layouts. Keep forbidding
it for open classes in order to error early, a client trying to subclass
an open class with such a reference from their property would already
see an error about members not deserializable.
Add a note to missing explicit `Sendable` conformance warning
(produced by `-Wwarning ExplicitSendable`) and a fix-it with
a suggestion to suppress `Senable` conformance via `~Sendable`.
If a type is suppressing `~Sendable` global-actor isolation shouldn't
make it `Sendable` and the compiler should diagnose cases were `Sendable`
comes from an isolated protocol.
