Stop pretending that an optional requirement is immutable via the `StorageImplInfo` request.
This approach has lead astray the conformance checker and may have had a negative impact
on other code paths, and it doesn't work for imported declarations because they bypass the
request. Instead, use a forwarding `AbstractStorageDecl::isSettableInSwift` method
that special-cases optional requirements.
insert 'some' instead of an explicit type parameter.
Replacing 'any' with 'some' allows the code to compile without further
changes, such as naming an explicit type parameter, and is future-proofed
for same-type requirements on primary associated types instead of needing
additional logic to add a 'where' clause.
When the conformance checker and override checker detect a difference in a function type’s @Sendable attribute that varies in an illegal way, they now check if the protocol/base class was imported with an @preconcurrency import, and either limit the diagnostic or suggest adding @preconcurrency to the import as appropriate.
Completes rdar://91109455.
Reimplement the final client of ActorIsolationRestriction, conformance
isolation checking, to base it on the new "actor reference" logic.
Centralize the diagnostics emission so we have a single place where we
emit the primary diagnostic (which is heavily customized based on
actor isolation/distributed/etc.) and any relevant notes to make
adjustments to the witness and/or requirement, e.g., adding
'distributed', 'async', 'throws', etc. Improve the diagnostics
slightly by providing Fix-Its when suggesting that we add "async"
and/or "throws".
With the last client of ActorIsolationRestriction gone, remove it
entirely.
Every protocol gets an 'identity conformance' rule [P].[P] => [P].
A trivially-stated circularity is always redundant because of this
rule, and we diagnose circular inheritance elsewhere as a hard
error, so just add a special case to skip adding such a rule here
to avoid the useless warning on top of the existing error.
- Don't pass 'verify' since it's now the default
- Update tests where diagnostics changed in a correct way to pass 'on' instead
- Delete compiler_scale/explicit_requirements_perf.swift since it's not testing anything with the requirement machine
The previous warning "must be explicitly marked as 'any'" isn't clear if
you don't already know the feature, this new phrasing should make it
clearer by including the correct spelling of the type as an example.
Fixes rdar://90384448
Although we have always checked classes to see if their @objc members had the same selectors, it turns out we never did this for protocols. Oops. Keep a table of ObjC selector names for protocols, just as we do for classes, and diagnose any conflicts between them.
Fixes rdar://80990066.
If a rule is not a protocol typealias rule, and does not contain any unresolved
symbols, do not attempt to eliminate it via a protocol typealias rule.
This fixes a bunch of cases where the RequirementMachine was overly-eager to
remove rules.
We don't want to pass in the outer generic signature here.
The base type's constraint type is written in terms of archetypes,
and we run generic signature queries against it with types appearing
in the protocol member. Since the protocol member has Self at
depth 0, index 0, prepending the outer generic signature to the
opened existential signature would produce incorrect results.
rule has a non-explicit, non-redundant rule in its rewrite path.
This fixes bogus redundancy diagnostics in cases where the canonical form
of a redundant rule is not explicit in source, e.g.
protocol Swappable2 {
associatedtype A
associatedtype B
associatedtype Swapped : Swappable2
where Swapped.B == A,
Swapped.Swapped == Self
}
in the above case, the canonical rule for `Swapped.B == A` is the rule
[Swappable2:Swapped].[Swappable2:A] => [Swappable2:B], which is not
explicit.
To avoid breaking the ABI of the standard library and possibly other
modules, we can't actually enable the new accurate logic for checking
protocol requirement overrides after all.
Just skip the check if the protocol requirement is generic to get
back the old behavior.
This avoids feeding invalid type parameters to the Requirement Machine
when a protocol requirement looks similar to a protocol requirement in
the inherited protocol but has an incompatible type.
Fixes https://bugs.swift.org/browse/SR-15826 / rdar://problem/89641535.
