Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
+@kadircet, he is tracking on this -- we had some discussion internally last week, but we don't reply on that thread yet (sorry).
clang-tools-extra/clangd/index/FileIndex.cpp | ||
---|---|---|
152 | instead of (or in addition to) providing the link, can we give a short summary? e.g. Subject and/or Object files might be part of multiple TUs. In such cases there will be a race and last TU to write the shard will win and all the other relations will be lost. We are storing relations in both places, as we do for symbols, to reduce such races. Note that they might still happen if same translation unit produces different relations under different configurations but that's something clangd doesn't handle in general. | |
354 | can you move this outside of the for loop, so that we do it only once. | |
clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp | ||
232 | do we still need this test? | |
396 | s/ShardSource/ShardHeader | |
clang-tools-extra/clangd/unittests/FileIndexTests.cpp | ||
571–573 | maybe mention that Sym1 belongs to a.h in the comment. stored in a.h (where Sym1 is stored) even tho the reference is dangling as Sym3 is unknown |
clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp | ||
---|---|---|
232 | this one was marked as resolved but i still don't see the reasoning. can we test this in fileindextests instead? we already test the sharding logic, we need to test the merging logic now. can we rather test it at FileSymbols layer directly? or is there something extra that i am misisng? |
Sorry, I had a response to that comment but accidentally left it as unsubmitted...
clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp | ||
---|---|---|
232 | I think it's still useful, yes. If someone makes a change to the way relations are stored in the future, they could regress this use case without a test specifically for it. |
thanks! (and sorry for taking too long on this one.)
clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp | ||
---|---|---|
232 | okay, i still think it is better to test on FileSymbols layer but not that important. |
Slightly simplified test (base class does not need to be a template to trigger the issue)
clang-tools-extra/clangd/unittests/BackgroundIndexTests.cpp | ||
---|---|---|
232 | The reason I'd like to have a test at this layer is so that we have a test that closely approximates the steps to reproduce: create files with certain contents and inclusion relationships between them, index them, and perform a particular query. I feel like internal abstractions like FileSymbols are liable to change over time through refactorings, and so tests written against them are less robust. Note, I don't think using BackgroundIndex is important for the kind of test I'd like; FileIndex would be fine too. However, I could not see how to use FileIndex with files that contain #include statements (didn't see a way to provide a MockFS or another way to get the includes to be resolved). That said, I did try to write an additional test using FileSymbols, but I found that:
|
instead of (or in addition to) providing the link, can we give a short summary? e.g.