A nested type of an archetype type might be concrete, for example, via a
same-type constraint:
extension SomeProtocol where SomeAssoc == Int {
... Self.SomeAssoc ...
}
This can happen in one of two ways; either the EquivalenceClass of the
nested type has a concrete type, or it is "fully concrete" because
there is no equivalence class and maybeResolveEquivalenceClass() returns
a ResolvedType storing the concrete type.
For some reason we didn't handle the second case here.
Fixes https://bugs.swift.org/browse/SR-13519 / rdar://problem/68531679
Previously, when saving NecessaryBindings for an async function, if a
type that was passed-in happened to be an archetype, a lookup for that
type's conformance would always be done. However, that lookup was not
always necessary or possible such as in the case where both the metadata
and the witness table were provided to the function in an async context.
Here, that is fixed by using the conformance that was seen when
constructing the NecessaryBindings if one is available.
rdar://problem/72397303
NecessaryBindings are used by both async functions and partial apply
forwarders. The latter are able to avoid bindings in some cases because
a new function is generated where the information that would otherwise
be available in the bindings can be made available. That is not the
case for async functions. A generic async function requires all of the
metadata and witness tables be passed along to it: unlike a partial
apply forwarder it isn't in any way specialized so this information
can't be recovered.
Previously, metadata bindings were always passed along to async
functions. However, destructuring that can be done for partial apply
forwarders was still being applied. This resulted in an inappropriate
and unexpected number of bindings in NecessaryBindings.
Here, that destructuring is avoided for metadata passed to async
functions.
Now, the full metadata required by async functions are passed along to
them as necessary.
rdar://problem/71816041
We checked for an import of a module named 'Foundation' before
checking if Objective-C interoperability was enabled, which
would lead to hilarious results.
Fixes <https://bugs.swift.org/browse/SR-13713> / <rdar://problem/70140319>.
Previously, when looking up a protocol method, the witness table was
always exepcted to be the final argument passed to the function.
That is true for sync protocol witnesses but not for async witnesses.
In the async case, the witness table is embedded in the async context.
Here, the witness table is dug out of the async context.
rdar://problem/71491604
The source range of the getter's body was set incorrectly;
both the start and the end were the property's location.
Instead, let's use the source range of the initializer
expression, which fixes an assertion in name lookup.
Fixes <rdar://problem/70732736>.
Metadata for an instance of a type is resolved by extracting it from an
instance of the class. When doing method lookup for an instance method
of a resilient class, the lowered self value was being obtained from the
list of arguments directly by indexing. That does not apply to async
functions where self is embedded within the async context. Here, the
self parameter is extracted from the async context so that the metadata
can in turn be extracted from it.
rdar://problem/71260862
Previously, when lowering the entry point of an async function, the
parameters were lowered to explosions that matched those of sync
functions, namely native explosions. That is incorrect for async
functions where the structured values are within the async context.
Here, that error is fixed, by adding a new customization point to
NativeCCEntryPointArgumentEmission which behaves as before for sync
functions but which simply extracts an argument from the async context
for async functions.
rdar://problem/71260972
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
