function body, map the result builder type into context.
This was already done for inferred result builder attributes; now,
the constraint system will map the builder type into context for all
result builder attributes applied to computed properties/functions.
We intended to introduce AST conversions that strip concurrency
attributes off of types associated with `@preconcurrency` decls.
But for VarDecl references, we stripped it too early, leading to
things like a MemberVarDecl that doesn't have `@Sendable` in its
result type, but the VarDecl it refers to does have it.
That caused crashes in SIL where types didn't match up. This patch
fixes things by delaying the stripping until the right point.
resolves rdar://98018067
If `buildBlock` is also unavailable, or the
builder itself is unavailable, continue to solve
using `buildPartialBlock` to get better
diagnostics.
This behavior technically differs from what is
specified in SE-0348, but only affects the invalid
case where no builder methods are available to use.
In particular, this improves diagnostics for
RegexComponentBuilder when the deployment target
is too low. Previously we would try to solve using
`buildBlock` (as `buildPartialBlock` is unavailable),
but RegexComponentBuilder only defines `buildBlock`
for the empty body case, leading to unhelpful
diagnostics that ultimately preferred not to use
the result builder at all.
rdar://97533700
Previously we would cache the result of the first
query, with any further query of
`ResultBuilder::supports` ignoring the
`checkAvailability` parameter. Separate out the
availability checking such that we compute the
information up front, and adjust the result
depending on `checkAvailability`.
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
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.
Unfortunately current approach of making a conversion independent of location
doesn't work when conversion is required for multiple arguments to the
same call because solver expects that either there are no Double<->CGFloat
conversions, or one of them has already been applied which is not the case.
The reason why locations weren't preserved in the first place is due to
how a solution is applied to AST - AST is mutated first and then, if there
are any conversions, they are applied to the already mutated version of
original AST. This creates a problem for Double<->CGFloat which depends
on an overload choice of injected call and it's impossible to find it based
on the mutated AST. But it turns out that this is only an issue in two
specific cases - conversions against contextual type and after optional injection.
This situations could be mitigated by dropping parts of the locator which are
unimportant for the Double<->CGFloat conversion - anchor in case of contextual
and `OptionalPayload` element(s) in case of optional injection.
Resolves: https://github.com/apple/swift/issues/59374
Instead of asking SILGen to build calls to `makeIterator` and
`$generator.next()`, let's synthesize and type-check them
together with the rest of for-in preamble. This greatly simplifies
interaction between Sema and SILGen for for-in statements.
Previously for-in target was actually an expression target, which means
certain type-checking behavior. These changes make it a standalone target
with custom behavior which would allow solver to introduce implicit
`makeIterator` and `next` calls and move some logic from SILGen.
Not checking success of constraint generation could lead to crashes
e.g. when follow-up code accesses something that hasn't been processed
due to error.
