Use the FullyQualified<Type> abstraction from the prior commit plus DescriptiveDeclKind to give a bit more information when issuing a missing member type diagnostic during type resolution.
15f8eb45ea (see PR#26632) introduced
refined didSet semantics where the `oldValue` parameter is skipped if it
isn't used. This would perform typechecking, but later try to set the
body to skipped and thus fire an assert.
For now, do not attempt to skip typechecking of didSet accessors. Still
skip outputting their SIL though.
"Function builders" are being renamed to "result builders". Add the
corresponding `@resultBuilder` attribute, with `@_functionBuilder` as
an alias for it, Update test cases to use @resultBuilder.
Previously, EmitPolymorphicParameters dealt directly with an Explosion
from which it pulled values. In one place, there was a conditional
check for async which handled some cases. There was however another
place where the polymorphic parameter was pulled directly from the
explosion. That missed case resulted in attempting to pull a
polymorphic parameter directly from an Explosion which contains only a
%swift.context* per the async calling convention.
Here, those parameters are now pulled from an EntryPointArgumentEmission
subclasses of which are able to provide the relevant definition of what
pulling a parameter means.
rdar://problem/70144083
I created a second copy of each test where the output changes
after disabling parser lookup. The primary copy now explicitly
calls the frontend with -disable-parser-lookup and expects the
new diagnostics; the *_parser_lookup.swift version calls the
frontend with -enable-parser-lookup and has the old expectations.
This allows us to turn parser lookup on and off by default
without disturbing tests. Once parser lookup is completely
removed we can remove the *_parser_lookup.swift variants.
This assert doesn't consider reference storage types in its predicate.
Look through them since they're not relevant to the type consistency
check it's trying to pick out.
The function builder transform creates pattern bindings parented
in other DeclContexts. If those pattern binding initializer
expressions in turn contain multi-statement closures, we will
try to perform unqualified lookups from those contexts when we
get around to type checking the closure body.
Change some unconditional casts to conditional casts in ASTScope
lookup, to handle this case. The casts are only performed while
checking if the initializer context is part of a 'lazy'
property, which doesn't apply here.
Fixes <rdar://problem/67265731>.
If both the 'other' and 'current' declarations are implicit, we don't
emit a diagnostic unless they are both derived from property wrappers
or lazy property storage.
However, we would still call setInvalid() unconditionally, which splats
an ErrorType into the interface type, which would crash in the AST
verifier if no other diagnostic was emitted.
Fixes <rdar://problem/67259506>.
In the included test case, conformance checking of Wrapper : B would
pick up typealias Foo as a witness for the associated type B.Foo.
However, this typealias Foo is defined in a constrained extension where
T : A, and the underlying type references the associated type A.Foo
on T.
The resulting substitution is invalid when the conformance Wrapper : B
is used in a context where T does not conform to A.
Instead, we should ignore this typealias entirely, since it appears
in an unusable constrained extension.
Fixes <rdar://problem/60219705>, <https://bugs.swift.org/browse/SR-12327>,
<https://bugs.swift.org/browse/SR-12663>.
The replacement types of the substitution map are either going
to be contextual types, or interface types using some generic
signature. There is no requirement that this generic signature
is the generic signature of the type declaration itself.
By using the generic signature of the type declaration, we
could incorrectly canonicalize generic parameters to concrete
types if the type itself was defined in a constrained extension,
as in the test case here.
Fixes <rdar://problem/65272763>.
This more powerful primitive is capable of
1) Detecting invalid classes
2) Detecting invalid superclasses
3) Detecting circularity in inheritance hierarchies
The attached crasher demonstrates the reason we need to validate all of these predicates. Simply put, a circular class hierarchy is always going to report the superclass conforms to any protocol with a declaration in the source. Leveraging this, one could construct any circular class hierarchy, and a conformance to Codable would immediately crash because we got as far as trying to build a CodingKeys enum with an absolutely nonsensical structure.
This also has the added benefit of de-complecting an enormous amount of codable conformance code.
rdar://66588925
* [Mangling] Add a new mangling to represent opaque return type for ObjC runtime name
* [Docs] Add the new 'Qu' mangling to 'Mangling.rst' document
* [Test] Update test invocation arguments
Make sure we consistently use getParentForLookup() and not getParent()
when looking at generic DeclContexts. This is because an extension or
protocol that is nested inside of another generic context must never
inherit generic parameters from the parent context.
We already had this invariant enforced in some places, but now that we
do it more consistently we can fix more crashes of this kind.
Fixes <rdar://problem/58813746>, <https://bugs.swift.org/browse/SR-13004>.
The maybeResolveEquivalenceClass() method can deallocate equivalence
classes, because it calls updateNestedTypeForConformance(), which
calls addSameTypeRequirement().
Therefore, the EquivalenceClass stored inside a ResolvedType could
become invalid across calls to maybeResolveEquivalenceClass().
This was a problem in one place in particular, when adding a new
same-type constraint between two type parameters.
Fix this by not caching the equivalence class of a PotentialArchetype
in the ResolvedType implementation. The only time an equivalence class
is now stored is when returning an unresolved type, which is acted
upon immediately.
Fixes <https://bugs.swift.org/browse/SR-12812>, <rdar://problem/63422600>.
The Space Engine maintains as one of its invariants that the AST it is
handed must at least typecheck. When swift typechecks patterns, the only
case one is allowed to form a Boolean pattern is when a literal is
expected, and the corresponding type of the pattern clause is exactly
Bool. This precludes the use of other types, including
ExpressibleByBooleanLiteral types, from matching. Thus, this code path
was never hit. That is, until we accidentally lifted the restriction on
enum case base name overloading too early. Now, it is possible for the
space engine to see the same constructor head that has subspaces with
different argument types. The space engine is relatively tolerant of
this bizarre situation, but in this one narrow case it was not.
This patch has a narrow fix to add the missing case to the
space engine. In the long term, we need to actually finish SE-0155 which
will make this crash structurally impossible once again.
Resolves rdar://65229620
Under certain circumstances, introducing a concrete same-type or
superclass constraint can re-introduce conformance constraints
which were previously redundant.
For example, consider this code, which we correctly support today:
protocol P {
associatedtype T : Q
}
protocol Q {}
class SomeClass<U : Q> {}
struct Outer<T> where T : P {
func inner<U>(_: U) where T == SomeClass<U>, U : Q {}
}
The constraint 'T == SomeClass<U>' makes the outer constraint
`T : P' redundant, because SomeClass already conforms to P.
It also introduces an implied same-type constraint 'U == T.T'.
However, whereas 'T : P' together with 'U == T.T' make 'U : Q'
redundant, the introduction of the constraint 'T == SomeClass<U>'
removes 'T : P', so we re-introduce an explicit constraint 'U : Q'
in order to get a valid generic signature.
This code path did the right thing for constraints derived via
concrete same-type constraints, but it did not handle superclass
constraints.
As a result, this case was broken:
struct Outer<T> where T : P {
func inner<U>(_: U) where T : SomeClass<U>, U : Q {}
}
This is the same example as above, except T is related via a
superclass constraint to SomeClass<U>, instead of via a concrete
same-type constraint.
The subtlety here is that we must check if the superclass type
actually conforms to the requirement source's protocol, because it
is possible to have a superclass-constrained generic parameter
where some conformances are abstract. Eg, if SomeClass did not
conform to another protocol P2, we could write
func foo<T, U>(_: T, _: U) where T : SomeClass<U>, T : P2 {}
In this case, 'T : P2' is an abstract conformance on the type 'T'.
The common case where this would come up in real code is when you
have a class that conforms to a protocol with an associated type,
and one of the protocol requirements was fulfilled by a default in
a protocol extension, eg:
protocol P {
associatedtype T : Q
func foo()
}
extension P {
func foo() {}
}
class ConformsWithDefault<T : Q> : P {}
The above used to crash; now it will type-check correctly.
Fixes <rdar://problem/44736411>, <https://bugs.swift.org/browse/SR-8814>..
