Check the availability of decls that declare an opaque return type to ensure they deploy to a
runtime that supports opaque types.
rdar://problem/50731151
Opaque result type archetypes can involve type variables, which
then get introduced into GenericSignatureBuilders and the
generated GenericSignatures. Allocate them in the proper arena
So we don’t end up with use-after-free errors.
Fixes rdar://problem/50309503.
Escapingness is a property of the type of a value, not a property of a function
parameter. Having it as a separate parameter flag just meant one more piece of
state that could get out of sync and cause weird problems.
Instead, always look at the noescape bit in a function type as the canonical
source of truth.
This does mean that '@escaping' is now printed in a few diagnostics where it was
not printed before; we can investigate these as separate issues, but it is
correct to print it there because the function types in question are, in fact,
escaping.
Fixes <https://bugs.swift.org/browse/SR-10256>, <rdar://problem/49522774>.
This is a defensive move to avoid duplicated work and guard against crashes
when a multi-expression closure body or TapExpr has not been type checked yet.
Fixes <rdar://problem/48852402>.
`openUnboundGenericType` eagerly tries to add conditional requirements
associated with chain of parents of the given type if type has been
declared inside of constrained extension. But one of the parent types
might be unbound e.g. `A.B` which means it has to be opened, which
by itself, would add such requirements.
Resolves: rdar://problem/49371608
This helps maintain invariants, such as the presence of a generic
parameter list implying the presence of a generic signature.
Fixes <rdar://problem/45317855>.
Let's keep track of type mismatch between type deduced
for the body of the closure vs. what is requested
contextually, it makes it much easier to diagnose
problems like:
```swift
func foo(_: () -> Int) {}
foo { "hello" }
```
Because we can pin-point problematic area of the source
when the rest of the system is consistent.
Resolves: rdar://problem/40537960
The `isSpecialized()` check didn’t account for the possibility that a
typealias in a parent of a nominal type could be non-generic when the
parent declaration was generic, leading to incorrect mangling that stated
that they were generic but had no generic arguments.
Fixes SR-8930 / rdar://problem/45216653 and rdar://problem/45813164.
In Swift 4.2, this example crashed. In Swift 5, it incorrectly diagnoses a type error. Eventually, it should actually succeed. For now, let's make sure we don't backslide to crashing.
We diagnose and flag these in finalize(), but we can encounter one
even earlier through resolveDependentMemberTypes(). Do the same
thing there that we already do in EquivalenceClass::getTypeInContext().
Fixes <rdar://problem/45328122>, <https://bugs.swift.org/browse/SR-9022>.
As an optimization, we don't even look for associated types in @objc
protocols. However, this could lead to broken invariants like "every
associated type has a witness" in ill-formed @objc protocols that do
have associated types.
Implement this optimization by checking whether the protocol has a
Clang node. Fixes rdar://problem/41425828 / SR-8094.
There's no need to instantiate archetypes in the generic environment
of the declaration being opened.
A couple of diagnostics changed. They were already misleading, and the
new diagnostics, while different, are not any more misleading than
before.
Because binding producer is going to attempt to unwrap optionals
and try the type, which would lead to infinite recursion because
dependent member types aren't bindable.
Resolves: rdar://problem/44770297
Works around an oddity of the associated type inference when the
potential witness is generic and returns (e.g.) Self.
Associated type inference needs to move off of archetypes for the
implementation to become sane. For now, this eliminates a crash.
Fixes rdar://problem/43591024.
We were building the following constraint, where $member and
$input are type variables and 'result' is a concrete type:
- Conversion($member, $input -> result)
When $member was fixed to a function type of arbitrary
arity, this would simplify to a conversion between $member's
result type and 'result'.
Instead, express this using the newly-added FunctionResult
constraint:
- FunctionResult($member, $result)
- Conversion($result, result)
I wasn't expecting this to change diagnostics, but it looks
like it did; I'm not going to bother investigating why,
because Pavel is going to rewrite contextual diagnostics soon
anyway. All but one are clear improvements.
Fixes <rdar://41416346> and <rdar://41416647>, two cases where
diagnostics regressed from -swift-version 3 to -swift-version 4.
