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.
* 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
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.
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.
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.
Lift the limitation of a single active diagnostic, which was a pretty
easy-to-hit footgun. We now maintain an array of active in-flight
diagnostics, which gets flushed once all them have ended.
For a method key path use the locator for the apply itself rather
than the member, ensuring we handle invalid cases where the apply is
the first component, and providing more accurate location info.
The invalid bit on PatternBindingDecl is very coarse grained, it
means any of the possible binding entries could be invalid.
Contextualization can handle invalid code anyway (e.g this is what we
do for `typeCheckBody`), so let's just avoid checking.
Correct several behaviors of availability checking in unavailable contexts that
were inconsistent with the checking model:
- Avoid diagnosing unintroduced and obsolted declarations in contexts that are
unavailable in the same domain.
- Diagnose unavailability normally in type signature contexts.
`return` statement withot an expression automatically gets an
implicit `()` which is allowed to be converted to types like
`()?` and `Any` or `Any?`. Let's remove a too strict assertion
that expected a contextual type to always be `()?` even
through in reality any type that `()` is convertible to is valid.
Resolves: rdar://152553143
Set an upper bound on the number of chained lookups we attempt to
avoid spinning while trying to recursively apply the same dynamic
member lookup to itself.
rdar://157288911
Now look through other opaque return types that appear in the
underlying type. This catches various forms of recursion that
otherwise would cause a SILGen or SILOptimizer crash.
- Fixes rdar://82992151.
While the intent behind this functor was noble, it has grown in complexity
considerably over the years, and it seems to be nothing but a source of
crashes in practice. I don't want to deal with it anymore, so I've decided
to just subsume all usages with LookUpConformanceInModule instead.
This check had two problems. First, it would assert upon encountering
a layout requirement, due to an unimplemented code path.
A more fundamental issue is that the logic wasn't fully sound, because
it would miss certain cases, for example:
protocol P {
associatedtype A
func run<B: Equatable>(_: B) where B == Self.A
}
Here, the reduced type of `Self.A` is `B`, and at first glance, the
requirement `B: Equatable` appears to be fine. However, this
is actually a new requirement on `Self`, and the protocol be rejected.
Now that we can change the reduction order by assigning weights to
generic parameters, this check can be implemented in a better way,
by building a new generic signature first, where all generic
parameters introduced by the protocol method, like 'B' above, are
assigned a non-zero weight.
With this reduction order, any type that is equivalent to
a member type of `Self` will have a reduced type rooted in `Self`,
at which point the previous syntactic check becomes sound.
Since this may cause us to reject code we accepted previously,
the type checker now performs the check once: first on the original
signature, which may miss certain cases, and then again on the new
signature built with the weighted reduction order.
If the first check fails, we diagnose an error. If the second
check fails, we only diagnose a warning.
However, this warning will become an error soon, and it really
can cause compiler crashes and miscompiles to have a malformed
protocol like this.
Fixes rdar://116938972.
`TypeSimplifier` may not eliminate type variables from e.g the
pattern types of pattern expansion types since they can remain
unresolved due to e.g having a placeholder count type. Make sure we
eliminate any remaining type variables along with the placeholders.
There's probably a more principled fix here, but this is a quick and
low risk fix we can hopefully take for 6.2.
rdar://154954995
If we fail to resolve the value type for a value generic parameter,
previously we would have returned a null Type, causing crashes
downstream. Instead, return an ErrorType, leaving a null Type for
cases where the generic parameter isn't a value generic at all.
rdar://154856417
Diagnostics can outlive the ConstraintSystem itself if we have a
diagnostic transaction for e.g `typeCheckParameterDefault`, make sure
we don't try to use a solver-allocated type as an argument.
Adjust isolation checking to handle misused `isolated` attribute
and let attribute checker property diagnose it.
Resolves: rdar://148076903
Resolves: https://github.com/swiftlang/swift/issues/80363
