Doing this when computing a canonical signature didn't really
make sense because canonical signatures are not canonicalized
any more strongly _with respect to the builder_; they just
canonicalize their requirement types.
Instead, let's do these checks after creating the signature in
computeGenericSignature().
The old behavior had another undesirable property; since the
canonicalization was done by registerGenericSignatureBuilder(),
we would always build a new GSB from scratch for every
signature we compute.
The new location also means we do these checks for protocol
requirement signatures as well. This flags an existing fixed
crasher where we still emit bogus same-type requirements in
the requirement signature, so I moved this test back into
an unfixed state.
This test case was also posted by a developer in
https://bugs.swift.org/browse/SR-11153, but it appears to
be a different problem that was fixed in Swift 5.2.
When the user spells an invalid precedence group, the Relation for that
group will fail to resolve the decl. We need to handle this in
checkPrecedenceGroup. Also add some asserts while I'm here.
rdar://75248642
A new implementation from "first principles". The idea is that
for a given conformance, we either have an explicit source
which forms the root of the requirement path, or a derived
source, which we 'factor' into a parent type/parent protocol
pair, and a requirement signature requirement.
We recursively compute the conformance access path of the
parent type and parent protocol, and append the path element
for the requirement.
This fixes a long-standing crasher, and eliminates two hacks,
the 'usesRequirementSource' flag in RequirementSource, and
the 'HadAnyRedundantConstraints' flag in GenericSignatureBuilder.
Fixes https://bugs.swift.org/browse/SR-7371 / rdar://problem/39239511
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.
