An extraneous argument doesn't have a corresponding parameter so the
information object for such an argument is not safe to produce.
Resolves: https://github.com/apple/swift/issues/60436
Resolves: rdar://98304482
In some circumstances opened type might not have a fixed binding.
A good example could be dependent sub-component produced for
result builder transformed code (connected via one-way constraints),
in such a case `OpenedTypes` would have outer generic parameters
but they might not be bound yet, so they have to be printed as
type variables.
Since result builder is just an AST transformation, the result
of a successful transform could be cache and reused with a different
`$__builderSelf` type.
The transform changes closure body into a multi-statement closure
with all of the implicit result builder calls and type-checks it
like a regular closure.
There are a couple of result builder specific changes mentioned below,
otherwise the logic to generate constraints and apply solutions is
unchanged:
- Placeholder variable: A variable declaration that doesn't have a
type deduced and infers it from its first use. If such a variable
has an initializer, it would be type-checked during solution application.
- TypeJoinExpr - an implicit expression that refers to a "join" variable
and a set of expressions that should all produce the same type that
becomes a type of a "join" variable.
Closures and functions that have result builder transform applied have to be
handled specially by the constraint generator because transformed body is
associated with the context (function or closure) only during solution application.
Move off `Type` based requests and onto `Decl`
based requests, utilizing name lookup's
`extractDirectlyReferencedNominalTypes` utility.
This allows us to better cache the results, and
avoids the need to guard against type variable
inputs when deciding whether or not to cache.
In ambiguity scenarios solutions are not applied back to the constraint
system, so it might not always have contextual type information when it
was recorded e.g. for a multi-statement closure.
Resolves: rdar://97396399
This was already enabled as part of `-enable-implicit-dynamic` but this
new flag allows turning on opaque type erasure all by itself whether or
not `dynamic` is added explicitly.
rdar://97375478
Instead of failing constraint generation by returning `nullptr` for an `ErrorExpr` or returning a null type when a type fails to be resolved, return a fresh type variable. This allows the constraint solver to continue further and produce more meaningful diagnostics.
Most importantly, it allows us to produce a solution where previously constraint generation for a syntactic element had failed, which is required to type check multi-statement closures in result builders inside the constraint system.
Rather than only setting the isolated-by-preconcurrency bit during
constraint application, track the closures it will be set for as part
of the constraint system and solution. Then, use that bit when
performing "strict concurrency context" checks and type adjustments,
so we don't treat an inferred-to-by-`@Sendable`-by-preconcurrency
closure in the solver as if it weren't related to preconcurrency.
Fixes the spurious warning from
https://github.com/apple/swift/issues/59910.
