ArcsinX wrote: >I was motivated to add an additional test to validate the actual on-disk >contents. background-index.test validates the workflow, but does not >explicitly validate what's being written out.
But the content is checked implicitly. If a go-to-definition request works ok after loading .idx files into memory, this implicitly means the data is correct. We also have numerous tests for serialization/deserialization of the RIFF format. I'm trying to understand if it's possible that background-index.test will pass, just like other RIFF serialization tests, but the test from this PR will fail, which would indicate a real bug? > Forgive me, but I'm not following. No file names or directories are being > changed. This test is validating that cracking open the respective .idx files > reveals the expected data Perhaps I misunderstood the test. Initially, I assumed we wanted to ensure that the URIs inside the .idx files are correct (because you mentioned path mapping). But in the test we are not checking the full path, only the base filename. For example, if the expected URI inside the .idx file is file:///a/b/foo.cpp, but in fact it turns out to be file:///c/d/foo.cpp, the test will pass. > This change validates existing functionality. I am simply trying to understand what specific potential problem is not covered by the existing tests, where a bug might occur that will be missed by the existing tests. https://github.com/llvm/llvm-project/pull/179956 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
