[TypeChecker] Re-work type-checking of string interpolations #61746
Conversation
|
This is still a draft because I need to to work out a few issues when string interpolations are used in closures (conjunction could get disconnected from the rest of the constraint system). |
xedin
force-pushed
the
rework-typechecking-of-tap-exprs
branch
from
47576fe to
2aee1c4
Compare
xedin
force-pushed
the
rework-typechecking-of-tap-exprs
branch
from
2aee1c4 to
6d01bdd
Compare
|
@swift-ci please smoke test |
|
@ahoppen Looks like the only thing that is left here are IDE work, would you mind looking into that when you have a chance? |
xedin
force-pushed
the
rework-typechecking-of-tap-exprs
branch
from
6d01bdd to
6695006
Compare
|
@swift-ci please smoke test |
1 similar comment
|
@swift-ci please smoke test |
ahoppen
force-pushed
the
rework-typechecking-of-tap-exprs
branch
2 times, most recently
from
399fcc5 to
7dc34c8
Compare
|
@swift-ci Please smoke test |
|
@swift-ci Please SourceKit stress test |
xedin
force-pushed
the
rework-typechecking-of-tap-exprs
branch
from
7dc34c8 to
d1db590
Compare
|
@swift-ci please smoke test |
|
@swift-ci please test source compatibility |
xedin
force-pushed
the
rework-typechecking-of-tap-exprs
branch
3 times, most recently
from
2f2427f to
1a81d7f
Compare
|
@swift-ci please smoke test macOS platform |
|
@swift-ci please test source compatibility |
1 similar comment
|
@swift-ci please test source compatibility |
|
@swift-ci please smoke test macOS platform |
xedin
force-pushed
the
rework-typechecking-of-tap-exprs
branch
from
820e2ea to
415cc77
Compare
|
@swift-ci please test source compatibility |
1 similar comment
|
@swift-ci please test source compatibility |
xedin
force-pushed
the
rework-typechecking-of-tap-exprs
branch
from
eb517da to
c3e0a83
Compare
|
@swift-ci please test source compatibility |
|
@swift-ci Please smoke test macOS |
Generate a conjunction for each tap expression body as soon as it gets a contextual type instead of separate post-factum type-checking via `typeCheckTapBody`.
It doesn't need access to anything besides external declarations which could be brought into the scope by context analyzer.
Since interpolations are now type-checked using conjunctions these diagnostics could be rank as part of the root expression or statement verification.
`test/Constraints/interpolation_segments.swift` has been removed because interpolations are now type-checked together with their context, so the separate type-checking test no longer applies.
…newly added method
…eserve connection to context Since "tap" bodies are now type-checked together with the context, it's imperative that the variable that represents an interpolation never gets disconnected from its context in the constraint system, otherwise it wouldn't be possible to determine types for the references.
xedin
force-pushed
the
rework-typechecking-of-tap-exprs
branch
from
c3e0a83 to
15eaca2
Compare
|
@swift-ci Please smoke test macOS |
|
@swift-ci please test source compatibility |
…ectly `TapExpr` do not form their own declaration context which means that using `context.getAsDeclContext` is incorrect for them.
xedin
force-pushed
the
rework-typechecking-of-tap-exprs
branch
from
15eaca2 to
f245b2b
Compare
|
@swift-ci Please smoke test macOS |
|
@swift-ci please test source compatibility |
… closures Both single- and multi-statement closures now use variable reference collector to identify variables used in the interpolation body, which means that it's not longer necessary to connect to the closure explicitly (if interpolation is contained in one).
xedin
force-pushed
the
rework-typechecking-of-tap-exprs
branch
from
f245b2b to
f9ec1e6
Compare
|
@swift-ci please smoke test macOS platform |
|
@swift-ci please test source compatibility |
|
Closing in favor of #63717 |
Type-check tap expressions the same way as we do closures. As soon as tap
expression gets a (contextual) type assigned - generate constraints for its
body (using conjunction constraint for incremental solving) and apply solution to
the body inline instead of using
typeCheckTapBody.