CSDiag could re-typecheck closure or other expression which has editor
placeholder inside allowing type variables be bound to unresolved
type, which doesn't really form a valid solution to be applied to AST.
So we need to guard against trying to transform placeholder into a call
to `_undefined` in such case, otherwise in asserts build it's going to
crash with an assert but in release build it would crash in some other
place e.g. xSILGen or trying to type-check captures.
Resolves: rdar://problem/48937223
Resolves: rdar://problem/51599529
When applying generic arguments to a local generic type within a generic
function, ensure that we correctly produce the contextual substitutions from
the generic function. Fixed with Pavel, who painstakingly tracked down
the bogus substitution.
Fixes SR-9954 / rdar://problem/48223824.
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.
