Details
Diff Detail
- Repository
- rL LLVM
Event Timeline
This is still racy if there were > 1 request. I wonder if there a better way to address this?
- As discussed offline, making consumeRequests take an argument for how many requests to receive before returning.
It just hit me that we should probably just wait for the async request to finish before returning from completion.
We might be doing this to reduce latency a little, but I don't recall us measuring that this provides a significant performance win.
Would that work?
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp | ||
---|---|---|
1141 ↗ | (On Diff #222618) | Could we wait with timeout here (a really high one, e.g. 10 seconds) here and assert we did not hit the timeout? This would ensure the test never actually runs into an infinite loop in practice. |
1152 ↗ | (On Diff #222618) | Maybe just use Requests.size()? |
1156 ↗ | (On Diff #222618) | Could you add a comment that the clients have to consume exactly Num requests? I believe anything else is a misuse:
|
1157 ↗ | (On Diff #222618) | Could we also assert no more than Num requests were captured? |
- Address comments
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp | ||
---|---|---|
1141 ↗ | (On Diff #222618) | I don't think it is that important, but sure I suppose a failing test is better than a hanging one :D |
LGTM
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp | ||
---|---|---|
1141 ↗ | (On Diff #222618) | Totally agree! Thanks! |
1161 ↗ | (On Diff #222890) | This code got me thinking whether compiler is allowed to do NRVO if the local variable is const. No need to do anything, just thinking out loud. |