All but 7 tests now passing. Those 7 tests either do not refer to these circumstances or do not seem to pass even when modified to accept type specifications.
It's permitted for a `witness_method` instruction to have multiple
type-dependent operands. This can happen when for example when one
local archetype is defined in terms of another.
rdar://159211502
Avoid walking TapExprs, SingleValueStmtExprs, and key paths. The latter
is important since they can contain invalid VarDecls that will no
longer be visited by the ASTWalker after key path resolution, so we
don't want to create case body vars for them.
This type is only intended for pattern matching against `nil`
and the solver shouldn't early attempt to infer this type for
`nil` for arguments of `==` and `!=` operators it should instead
be inferred from other argument or result.
Resolves: rdar://158063151
* When constructing instructions which have substitution maps: initialize those with the canonical SubstitutionMap
* Also initialize SILFunction::ForwardingSubMap with the canonical one
Non-canonical substitution maps may prevent generic specializations.
This fixes a problem in Embedded Swift where an error is given because a function cannot be specialized, although it should.
https://github.com/swiftlang/swift/issues/83895
rdar://159065157
Turns out we don't always set a completion callback for some unqualified
completion positions. Upgrade the check for a completion callback to
a check for a completion buffer to account for this. This avoids
unnecessary type-checker work as well as fixing a couple of
double-type-checking crashers.
Previously we would skip type-checking the result expression of a
`return` or the initialization expression of a binding if the contextual
type had an error, but that misses out on useful diagnostics and
prevents code completion and cursor info from working. Change the logic
such that we open ErrorTypes as holes and continue to type-check.
Eagerly bind invalid type references to holes and propagate contextual
type holes in `repairFailures`. This avoids some unnecessary diagnostics
in cases where we have an invalid contextual type.
We should have already type-checked a parent closure, and we wouldn't
be able to correctly locate the node anyway since it's not actually
part of the AST. While here, also walk up to the parent-most closure
instead of recursing to avoid unnecessary stack frames for nested
closures.
Pattern resolution currently invokes type resolution with this flag
since it's trying to see if it can treat a given expression as a
TypeRepr for e.g an enum pattern. Make sure we don't `setInvalid` on
such TypeRepr nodes since that will avoid diagnosing in cases where
the node also then gets treated as a TypeRepr for an ExprPattern,
where we actually want the diagnostic emitted.
We set an original expression on ErrorExpr for cases where we have
something semantically invalid that doesn't fit into the AST, but is
still something that the user has explicitly written. For example
this is how we represent unresolved dots without member names (`x.`).
We still want to type-check the underlying expression though since
it can provide useful diagnostics and allows semantic functionality
such as completion and cursor info to work correctly.
rdar://130771574
Disabling several TSan tests that are failing due to a bug in the thread
sanitizer. TSan appears to be setting the thread to ignored in the
`thr_exit` interceptor, and then immediately checking that the thread
isn't being ignored, and dying.
```
ThreadSanitizer: main thread finished with ignores enabled
One of the following ignores was not ended (in order of probability)
```
rdar://158450231
Resolving only a structural type meant we weren't checking generic
constraints, allowing invalid extensions to get past the type-checker.
Change to resolve an interface type.
