This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Make sure headers are available in FS inside FindSymbolsTests
AbandonedPublic

Authored by kadircet on Jun 28 2020, 2:08 PM.

Details

Reviewers
sammccall

Diff Detail

Event Timeline

kadircet created this revision.Jun 28 2020, 2:08 PM
Herald added a project: Restricted Project. · View Herald TranscriptJun 28 2020, 2:08 PM

Why? workspaceSymbols depends on the index only.
ISTM the dynamic index + blockUntilIdle should be enough - what does the FS have to do with it?
Oh, is this a race condition due to async preamble builds?


I think a slightly more principled fix here is that we should just use TestTU + clangd::getWorkspaceSymbols directly and stop using ClangdServer.
We can land this as-is if tests are flaking and need a quick fix and TestTU is too invasive, but it seems it shouldn't be complicated. WDYT?

Why? workspaceSymbols depends on the index only.
ISTM the dynamic index + blockUntilIdle should be enough - what does the FS have to do with it?

Yes it does, but tests that I updated are also adding a "foo.cpp" file, which tries to include some headers. Those headers can only be retrieved from FS and not from the dirty buffer (that has been populated via Server.AddDocument).
Hence even though this change should be invisible for the outcome of the tests (as symbols will still be populated due to indexing of headers), this ensures we've restored them to the proper state after d26721776ff08e0ecdd73b8851c44032d7c0a366
I don't think these tests ever wanted to index the headers directly (as main files), they rather intended the headers to be indexed through foo.cpp including them, but I wasn't sure about that assumption hence didn't make that change.

Oh, is this a race condition due to async preamble builds?

There was a race condition (due to modification of FS while ASTWorker was working and MockFS's lack of being thread-safe) that has been fixed in d26721776ff08e0ecdd73b8851c44032d7c0a366.
I suppose you are talking about the recent flakes on some build bots, it wasn't my intention to fix them in this patch (nor I think this has patch will have any effects on that flakiness, if you think so please
elaborate, as it likely means I am missing something)


I think a slightly more principled fix here is that we should just use TestTU + clangd::getWorkspaceSymbols directly and stop using ClangdServer.
We can land this as-is if tests are flaking and need a quick fix and TestTU is too invasive, but it seems it shouldn't be complicated. WDYT?

that option also SG, but I think there's value in having a couple tests that are invoked through TUScheduler to test the full production behaviour.
So I would at least copy some exemplar ones to ClangdTests.

Yes it does, but tests that I updated are also adding a "foo.cpp" file, which tries to include some headers. Those headers can only be retrieved from FS and not from the dirty buffer (that has been populated via Server.AddDocument).
Hence even though this change should be invisible for the outcome of the tests (as symbols will still be populated due to indexing of headers), this ensures we've restored them to the proper state after d26721776ff08e0ecdd73b8851c44032d7c0a366
I don't think these tests ever wanted to index the headers directly (as main files), they rather intended the headers to be indexed through foo.cpp including them, but I wasn't sure about that assumption hence didn't make that change.

Ah right, I think that change is safe and a good idea (assuming tests pass).
Essentially before the test is doing the wrong thing for setup, changing it to doing the right thing seems better than changing it to do both!

I think a slightly more principled fix here is that we should just use TestTU + clangd::getWorkspaceSymbols directly and stop using ClangdServer.
We can land this as-is if tests are flaking and need a quick fix and TestTU is too invasive, but it seems it shouldn't be complicated. WDYT?

that option also SG, but I think there's value in having a couple tests that are invoked through TUScheduler to test the full production behaviour.
So I would at least copy some exemplar ones to ClangdTests.

Maybe one... isn't this covered in our lit tests though?

kadircet abandoned this revision.Jul 1 2020, 4:31 AM

abandoning in favor of D82944