This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Run SignatureHelp using an up-to-date preamble, waiting if needed.
ClosedPublic

Authored by sammccall on Aug 29 2018, 9:28 AM.

Details

Diff Detail

Repository
rL LLVM

Event Timeline

sammccall created this revision.Aug 29 2018, 9:28 AM

(This needs new TUScheduler tests for Consistent mode, but would like some feedback on the implementation first)

sammccall updated this revision to Diff 163121.Aug 29 2018, 9:29 AM

Finish a sentence

The implementation is really simple. LG!
To get proper operation order in tests, we can wait in the diagnostics callback that runs on the worker thread (IIRC, we do that in some of the other tests too).

clangd/TUScheduler.cpp
188 ↗(On Diff #163121)

As discussed offline, it looks like it shouldn't be a problem to call it from the working thread, so we could probably remove this restriction from the comment.
Not that it's the right thing to do or that we have a use-case for that yet.

474 ↗(On Diff #163121)

It seems we could remove the special-casing of RunSync and still get correct results (the Requests queue is always empty).
But feel free to keep it for clarity.

clangd/TUScheduler.h
123 ↗(On Diff #163121)

Maybe use a strongly-typed enum outside the class?
TUScheduler::Stale will turn into PreambleConsistency::Stale at the call-site. The main upside is that it does not pollute completions inside the class with enumerators.

Just a suggestion, feel free to ignore.

sammccall updated this revision to Diff 163322.Aug 30 2018, 6:55 AM
sammccall marked 2 inline comments as done.

Add test, address comments.

This revision is now accepted and ready to land.Aug 30 2018, 7:10 AM
This revision was automatically updated to reflect the committed changes.
sammccall added inline comments.Aug 30 2018, 8:15 AM
clangd/TUScheduler.cpp
474 ↗(On Diff #163121)

Right, of course :-)
Replaced this with an assert before we write to the queue.

clangd/TUScheduler.h
123 ↗(On Diff #163121)

Yeah, the downside to that is that it *does* pollute the clangd:: namespace. So both are a bit sad.

This header is fairly widely visible (since it's included by clangdserver) and this API is fairly narrowly interesting, so as far as completion goes I think I prefer it being hidden in TUScheduler.

Hi Sam,

It took a very long time to identify it, but this commit broke ARMv7
bots, where this test hangs. Logs are available here (initial ones
are too old):

http://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/3685/steps/ninja%20check%201/logs/stdiohttp://lab.llvm.org:8011/builders/clang-cmake-armv7-quick/builds/3685/steps/ninja%20check%201/logs/stdio

Thanks,
YvanOn Thu, 30 Aug 2018 at 17:15, Sam McCall via Phabricator via
cfe-commits <cfe-commits@lists.llvm.org> wrote:

sammccall added inline comments.

Comment at: clangd/TUScheduler.cpp:474
+ llvm::unique_function<void(std::shared_ptr<const PreambleData>)> Callback) {
+ if (RunSync)

+ return Callback(getPossiblyStalePreamble());

ilya-biryukov wrote:

It seems we could remove the special-casing of RunSync and still get correct results (the Requests queue is always empty).
But feel free to keep it for clarity.

Right, of course :-)
Replaced this with an assert before we write to the queue.

Comment at: clangd/TUScheduler.h:123
+ /// Controls whether preamble reads wait for the preamble to be up-to-date.
+ enum PreambleConsistency {

+ /// The preamble is generated from the current version of the file.

ilya-biryukov wrote:

Maybe use a strongly-typed enum outside the class?
TUScheduler::Stale will turn into PreambleConsistency::Stale at the call-site. The main upside is that it does not pollute completions inside the class with enumerators.

Just a suggestion, feel free to ignore.

Yeah, the downside to that is that it *does* pollute the clangd:: namespace. So both are a bit sad.

This header is fairly widely visible (since it's included by clangdserver) and this API is fairly narrowly interesting, so as far as completion goes I think I prefer it being hidden in TUScheduler.

Repository:

rL LLVM

https://reviews.llvm.org/D51438


cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

yroux added a comment.Sep 18 2018, 1:55 PM

Seems that it was fixed earlier today.

Thanks,
Yvan