HighCommander4 wrote: > > Things already fail at the SymbolCollector level > > Holy how the heck did you figure that one out.
It was an adventure :) I started by picking a specific constructor defined in a header file in my unreduced codebase, and a specific `make_unique` call that should reference it in a source file, to investigate. To start narrowing down the problem, I wanted to see whether the reference made it to the on-disk representation of the background index contents. To do this, I used the [`dexp`](https://searchfox.org/llvm/source/clang-tools-extra/clangd/index/dex/dexp/Dexp.cpp) tool to explore the contents of the index files. I started by doing a lookup in the index shard for the header file, to find the constructor's symbol ID. Then, knowing that references are stored in the shard for the file in which the reference occurs, I then searched for references to that symbol ID in the source file's index shard, and saw that there were none. To understand where the reference is lost, I added some logging to various codepaths that process references between their initial collection in SymbolCollector, and their writing to disk. I made the logging conditional on the referenced symbol ID being the constructor's symbol ID from the previous step. (Symbol IDs are stable, they're basically a hash of a symbol's qualified name + signature if applicable.) I reindexed the codebase with the added logging, and that's how I realized the reference I'm looking for wasn't being collected in the first place. Since the reference _was_ collected when the source file was the only file in `compile_commands.json`, and wasn't when there were also other files, it followed that SymbolCollector was exhibiting stateful behaviour that depended on what files were indexed before. Since the "skip function bodies in already-seen files" optimization I encountered in https://github.com/clangd/clangd/issues/1104 was an example of such stateful behaviour, and finding indirect constructors depended on having function bodies, I hypothesized that this was the cause, and verified it with some additional logging. https://github.com/llvm/llvm-project/pull/169742 _______________________________________________ cfe-commits mailing list [email protected] https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
