A DependentMemberType can either have a bound AssociatedTypeDecl,
or it might be 'unresolved' and only store an identifier.
In maybeResolveEquivalenceClass(), we did not handle the unresolved
case when the base type of the DependentMemberType had itself been
resolved to a concrete type.
Fixes <rdar://problem/71162777>.
The parser attempts to recover here by producing a broken VarDecl with
no parent pattern. The DeclChecker sees this when trying to install
a default initializer in the linked regression test and crashes because
it tries to look into a null parent pattern.
rdar://74154023
The Python build system always enables concurrency, but CMake has it
disable by default. Collaborators that do not use the Python build
system and use directly CMake will have it disable, unless they
explicitely enable it. If the tests are not marked as requiring the
concurrency features, the tests will fail to execute when concurrency is
disabled.
The changes add the `REQUIRES: concurrency` line to many tests that deal
with concurrency, but wasn't marked as such.
Looking for the parent source file is going to fail when the paramter
we're interested in comes from a module context. Request the correct
top-level context in those situations.
rdar://73379770
It is possible for ClassDecl::getSuperclassDecl() to succeed but for
ClassDecl::getSuperclass() to fail. This happens if the superclass is
a generic type and one of the generic arguments could not be resolved,
or does not satisfy the generic requirements, for example; in that
case, a BoundGenericType cannot be formed.
In a couple of places we were not prepared for this possibility.
Let's recover by making judicious use of ErrorType.
Fixes <rdar://problem/73169149>.
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>.
