- This option forces a preamble rebuild to handle the odd case of a missing header file being added
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
Unit tests: pass. 62418 tests passed, 0 failed and 845 were skipped.
clang-tidy: fail. clang-tidy found 0 errors and 2 warnings. 2 of them are added as review comments below (why?).
clang-format: fail. Please format your changes with clang-format by running git-clang-format HEAD^ or applying this patch.
Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml
Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.
Unit tests: pass. 62418 tests passed, 0 failed and 845 were skipped.
clang-tidy: fail. clang-tidy found 0 errors and 2 warnings. 2 of them are added as review comments below (why?).
clang-format: fail. Please format your changes with clang-format by running git-clang-format HEAD^ or applying this patch.
Build artifacts: diff.json, clang-tidy.txt, clang-format.patch, CMakeCache.txt, console-log.txt, test-results.xml
Pre-merge checks is in beta. Report issue. Please join beta or enable it for your project.
Thanks for this. It makes me a bit sad but I don't really see a clean way to make this "just work".
clang-tools-extra/clangd/ClangdLSPServer.cpp | ||
---|---|---|
650 | Rather than plumbing this down many levels as yet-another-bool-param, can we shove it into either ParseInputs or ParseOptions? It's kind of a stretch for the API as we won't make use of it everywhere that ParseInputs is used, but I think it's better than adding a niche boolean param everywhere. | |
clang-tools-extra/clangd/Protocol.h | ||
656 | Nit: the preamble is an implementation detail here, an even higher-level description would be e.g. Force a complete rebuild of the file, ignoring all cached state. Slow! | |
661 | just bool forceReload = false; - we don't bother modelling this as a tristate if there's a well-defined defaut. (Though I'm sure there are places where we are inconsistent...) | |
661 | somehow "rebuild" seems clearer than "reload" to me, because we're not being very specific about what we're loading. Also allowCache (with inverted sense) might be clearer. | |
clang-tools-extra/clangd/TUScheduler.cpp | ||
434 | no need to pass a separate parameter through to buildPreamble - if you're forcing a preamble rebuild then just don't bother getting the old preamble. OldPreamble is null and you get the behaviour you want. (The logging will be slightly off - "first preamble" - but I don't think it's worth fixing) |
clang-tools-extra/clangd/ClangdLSPServer.cpp | ||
---|---|---|
650 | Done, this cleaned up the tests |
Looks pretty good now, thanks! Test needs to be more precise (doesn't actually test the behavior at present, I think).
clang-tools-extra/clangd/Compiler.h | ||
---|---|---|
41 | Hmm, on thinking further I do think this belongs in ParseInputs next to Contents or CompileCommands, as these things are things that affect the parse but *don't* invalidate caches. | |
41 | this is a good place for a comment explaining what this does specifically (prevents reuse of cached preamble/ast) | |
clang-tools-extra/clangd/Protocol.h | ||
660 | = false, and remove "disabled by default" from comment | |
clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp | ||
618 | This test doesn't actually verify that the preamble was rebuilt, just that the AST was. | |
630 | I don't think this abstraction is useful since you just have 3 calls and two of them need the actual diagnostics. You could have diag callbacks inline easily enough: vector<vector<Diag>> diags; update(..., [] { diags.push_back(...) }) update(..., [] { ADD_FAILURE(...) }) update(..., [] { diags.push_back(...) }) blockUntilIdle(); EXPECT_THAT(diags, ElementsAre( /* First */ElementsAre(...missing header...), /* Last */IsEmpty()); |
LG, thanks! Just a nit about further simplifying the test, up to you.
clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp | ||
---|---|---|
629 | this still feels just a bit obfuscated, what about more directly: ParseInputs I = getInputs(Source, SourceContents); updateWithDiags(..., I, [] { ... }); Files[Header] = ...; updateWithDiags(...); I.ForceRebuild = true; updateWithDiags(...); |
clang-tools-extra/clangd/unittests/TUSchedulerTests.cpp | ||
---|---|---|
629 | still needed to recreate ParseInputs but done |
Rather than plumbing this down many levels as yet-another-bool-param, can we shove it into either ParseInputs or ParseOptions?
e.g. bool ParseInputs::AllowCached = true; and set it to false here?
It's kind of a stretch for the API as we won't make use of it everywhere that ParseInputs is used, but I think it's better than adding a niche boolean param everywhere.