This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Fix raciness in code completion tests
ClosedPublic

Authored by kadircet on Oct 1 2019, 7:33 AM.

Event Timeline

kadircet created this revision.Oct 1 2019, 7:33 AM
Herald added a project: Restricted Project. · View Herald TranscriptOct 1 2019, 7:33 AM

This is still racy if there were > 1 request. I wonder if there a better way to address this?

kadircet updated this revision to Diff 222618.Oct 1 2019, 7:52 AM
  • 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
1142

Could we wait with timeout here (a really high one, e.g. 10 seconds) here and assert we did not hit the timeout?
The wait helper from Threading.h is a nice API to do this.

This would ensure the test never actually runs into an infinite loop in practice.

1151

Maybe just use Requests.size()?

1155

Could you add a comment that the clients have to consume exactly Num requests?

I believe anything else is a misuse:

  • if there are more than Num requests coming in, we'll get a similar data race to the one we're trying to fix.
  • if there are less than Num requests we'll wait for the next request indefinitely
1156

Could we also assert no more than Num requests were captured?
To avoid unintentional misuse of the default call.

kadircet updated this revision to Diff 222890.Oct 2 2019, 12:30 PM
kadircet marked 5 inline comments as done.
  • Address comments
clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
1142

I don't think it is that important, but sure I suppose a failing test is better than a hanging one :D

ilya-biryukov accepted this revision.Oct 4 2019, 1:19 AM
ilya-biryukov marked an inline comment as done.

LGTM

clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
1142

Totally agree! Thanks!

1160

This code got me thinking whether compiler is allowed to do NRVO if the local variable is const.
Given that the object is not const, we definitely cannot call a move constructor to go from Reqs to the return value.
OTOH, if NRVO applies here, this shouldn't matter.

No need to do anything, just thinking out loud.

This revision is now accepted and ready to land.Oct 4 2019, 1:19 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptOct 7 2019, 10:15 PM