[CodeCompletion] Call sawSolution when type checking a result builder #41846
Conversation
ahoppen
force-pushed
the
pr/saw-solution-in-result-builder
branch
from
8408133 to
135c266
Compare
|
@swift-ci Please smoke test |
|
@swift-ci Please SourceKit stress test |
| filterSolutionsForCodeCompletion(solutions, analyzer); | ||
| for (const auto &solution : solutions) { | ||
| cs.getASTContext().CompletionCallback->sawSolution(solution); | ||
| } |
There was a problem hiding this comment.
Do we want to just stop here instead of going farther and emitting diagnostics?
There was a problem hiding this comment.
I’ll try that in a follow-up PR because I’m curious to see if stopping early improves performance and if yes, by how much.
There was a problem hiding this comment.
I think it makes sense regardless of performance impact because these diagnostics would just get emitted to be discarded.
There was a problem hiding this comment.
I mostly want to know how big the performance win is. And I wanted to get this one merged to unblock the argument completion PR ;-)
There was a problem hiding this comment.
Yeah, no worries, I'm not saying it should have been added in this PR, just want to make a point about it being logically correct thing to do :)
|
Wohooooooo 🎉 🥳 🎉 This fixes 1/3 of all known stress tester issues and improves code completion performance in slow cases by 10% - 20% |
The following issues have been fixed by swiftlang/swift#41846 - SR-14694 (partially) - SR-14693 - SR-14704 - SR-14739 - SR-14889 - SR-14693 - SR-14693
The following issues have been fixed by swiftlang/swift#41846 - SR-14694 (partially) - SR-14693 - SR-14704 - SR-14739 - SR-14889 - SR-14693
Before, we weren’t calling
sawSolutionwhen performing solver based completion inside a result builder. That was no good because we always ended up in the fallback case.This also contains some minor restructuring how solutions are filtered that I carried over from the argument-completion-to-solver-based PR.