This is not supported for the same reason you can't have a noncopyable
variadic parameter, but the code was hard-coded to check for copyability
only.
Generalize this to apply the generic signature for Array via the
common code path, and add a custom note to explain why those requirements
are checked in the first place.
Cleaning this up also fixed some fuzzer crashes.
Reported on the forums:
https://forums.swift.org/t/variadic-escapable-arguments-crash-the-compiler/86727/2
When a pattern conformance in the pack is invalid (e.g. its underlying
conformance failed because of a prior diagnostic),
`getAssociatedConformance` returned an invalid `ProtocolConformanceRef`
whose `getType()` is null. The null type was pushed into `packElements`
and tripped an assertion in `PackType::get`. Substitute `ErrorType` for
the null so substitution can complete and the existing diagnostics
surface to the user.
Fixes https://github.com/swiftlang/swift/issues/88434.
`any Foo & ~Copyable` where `Foo: AnyObject` triggered a null Type in
the `inverse_with_class_constraint` diagnostic: the layout requires a
class via protocol refinement, but `getSuperclass()` is null with no
explicit superclass term. Select the "AnyObject" branch when there's no
concrete superclass.
resolves rdar://161839720 (Type checker crash on illegal existential
type)
If the fix-it would remove a range that is followed by a newline and the
remaining text on the line is empty or all whitespace then remove the entire
line. This produces better results when a fix-it removes an attribute that is
written on a line by itself.
Additional test coverage of expected signatures.
There's currently no syntax to suppress the `t_1_0: Copyable`
default requirement in the opaque return type. But we at least
now support suppression for the associated type.
Opaque return types are special type declarations that have it
own nested generic signature. Thus, given this:
```
protocol P<A> { associatedtype A: ~Copyable }
func f<T: ~Copyable>() -> some P<T> {}
```
The generic signature for f is <T where T Escapable>, and
for the opaque return type, its nested signature ends up as
```
<X where X: P, X.A == T>
```
With SE-503, we will now also expand a default for the suppressed
primary associated type, so the signature after expansion becomes
```
<X where X: P, X.A == T, X.A: Copyable>
```
It would be smarter to effectively have this rule
```
X.A == T, T: ~Copyable
----------------------
X.A: ~Copyable
```
where we infer the inverse on X.A to cancel-out the
expanded default X.A: Copyable. We already do this for
two in-scope type parameters, and it would be better if
we did it if one side was out-of-scope, but that would
be source-breaking to do in general.
In the case of opaque return types, the fact that
it has a nested generic signature seems more an
artifact of the implementation. There also is little
risk of source break, as the only kinds of same-type
requirements that can appear are from parameterized
protocol type.
The experimental suppressed associated types prior to
SE-503 wouldn't be broken by this change, as they do
not infer defaults that need suppression, and we only
filter-out requirements from defaults expansion, rather
than explicitly-written ones.
rdar://175500824
The `Assoc.Assoc: ~Copyable` cancels out the assoc type default
inferred for it from the `Assoc: Recur` requirement in the protocol's
signature. This seems to cause that level and any deeper levels to no
longer infer a default.
We have coverage for this in the signatures tests but not here.
We need to start moving people over to using the version of
suppressed associated types that has the officially accepted
behavior according to SE-503, and that is via
`SuppressedAssociatedTypesWithDefaults`.
To allow for time to migrate to the new version, I'm introducing
the deprecation message as a warning for now.
This set of changes also moves most of the test suite over to using
the officially accepted version.
rdar://172231663
This replaces #87114, aligning the `BorrowingSequence` protocols and
related types to the Swift Evolution proposal, and without included
reparenting of `Sequence`.
The only way to avoid a source break when introducing a
reparenting is to allow implied conditional conformance
to a @reparentable protocol, as prior code would not have
explicitly stated it.
We were walking the extensions of protocols in
requirement lowering and in getInheritedProtocols
to also count the @reparented entries in all
extensions. I had already seen some request
evaluator cycles triggered by this with objc
protocols, and it seems unnessecary as it's
actually a benefit to force people to write the
inheritance on the protocol itself.
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.
We actually have to check this constraint, otherwise we accept invalid
code where we're referencing a protocol requirement with a concrete
base type which conditionally conforms to the protocol, but the
conditional requirements are unsatisfied.
However, we still need to skip it for AnyObject lookup, Distributed
Actors, and some weird edge case in conformance checking for isolated
conformances.
We should clean this up further later, but for now this closes a soundness
hole.
Fixes rdar://168129757.
The generic parameter at the root of a DependentMemberType is
the main thing we care about in terms of the scoping rule.
We have a check for ineffective / invalid inverses in a later
phase, so if the suppression on the type member was wrong then
we should still raise an error about it.
Private member witnessing a public constraint should be deprecated.
Previously existing workaround is checked and compiler emits a warning
when strict access check is not passed. Test files were fixed to expect
the corresponding warning.
rdar://74904373
If a generic parameter is same-type-constrained to an outer type
parameter, it doesn't have to appear in the subscript's signature.
- Fixes https://github.com/swiftlang/swift/issues/50917.
We've had a load-bearing optimization that avoids rebuilding
the generic signature of the protocol extension to avoid a
cycle involving a typealias in the extension that's mentioned
as a requirement in the protocol, for example:
```
public protocol P3 {
associatedtype A
}
public protocol P4: P3 where A == B {}
extension P4 {
public typealias B = String
}
```
What was happening is that we're inside a
StructuralRequirementsRequest, so we're performing TypeResolution
in the Structural stage. When we encounter this typealias that's
within a protocol extension, we'd end up accidentally requesting
the interface type of that alias through
`TypeChecker::substMemberTypeWithBase`
(via `aliasDecl->getUnderlyingType()`).
What we should do instead is call `aliasDecl->getStructuralType()`
and skip the substitution during that stage.
There happened to already be code doing this, but it was only
kicking in if the DeclContext `isa<ProtocolDecl>`, which excludes
extensions of a protocol. I see no reason why extensions of a
protocol should be excluded, so I assume it was unintentional.
Thus, the fix boils down to using `DeclContext::getSelfProtocolDecl`
which does include extensions of protocols. With this fix, the
optimization is no longer load-bearing on the example above.
See the history of this hack in f747121080
or rdar://problem/129540617
This is similar to SuppressedAssociatedTypes, but infers
default requirements when primary associated types of
protocols are suppressed. This defaulting for the primary
associated types happens in extensions of the protocol,
along with generic parameters, whenever a source-written
requirement states a conformance requirement for the protocol.
Thus, the current scheme for this defaulting is a simplistic,
driven by source-written requirements, rather than facts
that are inferred while building generic signatures.
Defaults are not expanded for infinitely many associated types.
rdar://135168163
Support pack expansion types in term rewriting, maintaining shape invariants and not
throwing assertions unnecessarily.
Additional tests added for an inifinite case and a concrete case.
The "iterate until fixed point" would cause an infinite loop where we
wrap type parameter packs in a PackElementType and increase the level
forever otherwise.
This was a regression from commit 103428fe80.
Fixes rdar://160804717.
This adds the -verify-ignore-unrelated flag. When -verify is used without -verify-ignore-unrelated, diagnostics emitted in buffers other than the main file and those passed with -verify-additional-file (except diagnostics emitted at <unknown>:0) will now result in an error. They were previously ignored. The old behaviour is still available as opt-in using -verify-ignore-unrelated, but by being strict by default it should make it harder to accidentally miss diagnostics.
To avoid unnecessary performance overhead, -verify-additional-file is still required to parse the expected-* directives in files other than the main file.
Matching existential types could introduce `InstanceType` element
at the end of the locator path, it's okay to look through them to
diagnose the underlying issue.
Filter out any duplicate notes to help cut down on the noise for
request cycle diagnostics. Some of the note locations here still aren't
great, but this at least stops us from repeating them for each
intermediate request.
These are tests that fail in the next commit without this flag. This
does not add -verify-ignore-unrelated to all tests with -verify, only
the ones that would fail without it. This is NFC since this flag is
currently a no-op.
Slava Pestov
Hamish Knight
Allan Shortlidge
Ben Cohen
Kavon Farvardin
Nate Cook
Rintaro Ishizaki
Sam Pyankov
Xi Ge
Ryan Mansfield
Kathy Gray
Pavel Yaskevich
Henrik G. Olsson
Pavel Yaskevich
Henrik G. Olsson