This is an archive of the discontinued LLVM Phabricator instance.

[clangd] Add ability to change storage directory of index files
AbandonedPublic

Authored by crr0004 on May 30 2021, 4:45 AM.

Details

Reviewers
sammccall
Summary

This adds a new option to change the root directory of where the index files get stored.
I mainly added this because I am doing profiling of indexing and needed a way for multiple instances of index files not to conflict with each other.

The extact naming of variables and the help text can be changed, I just guessed.

I tried to add a test for the change however I couldn't find a way to neatly check storage root directory. I am not sure if the test I've written is all that helpful.

Diff Detail

Event Timeline

crr0004 created this revision.May 30 2021, 4:45 AM
crr0004 requested review of this revision.May 30 2021, 4:45 AM
nridge added a subscriber: nridge.May 30 2021, 8:05 PM

I mainly added this because I am doing profiling of indexing and needed a way for multiple instances of index files not to conflict with each other.

If this is solely for testing purposes, can't you make use of --compile-commands-dir instead? You'll also need to copy your compile_commands.json into that directory.

Strictly speaking you could, assuming you have a compile database and it's okay to have copies or symlinks of the database.

I would have probably done that if I had realised I could.

That does speak to another issue though; moving the compile database to move the index files is not very intuitive. We could improve the help text around compile commands to explain fully the implications of the file which might help.

I really just wanted direct control of where the index files go.

Strictly speaking you could, assuming you have a compile database and it's okay to have copies or symlinks of the database.

Well you wouldn't have index shards without a compilation database anyway though.

That does speak to another issue though; moving the compile database to move the index files is not very intuitive. We could improve the help text around compile commands to explain fully the implications of the file which might help.

I am not sure if this is something that is interesting to the average user. Hence we've only documented in the designs and the code:

Before indexing each file, the index checks for a cached *.idx file on disk. After indexing, it writes this file. This avoids reindexing on startup if nothing changed since last time.
These files are located in .cache/clangd/index/ next to compile_commands.json. For headers with no CDB, such as the standard library, they are in clangd/index under the
user’s cache directory ($XDG_CACHE_HOME, DARWIN_USER_CACHE_DIR, or %LocalAppData%).

This is definitely an interface that makes sense for the purpose you describe (profiling index performance) but I'm less convinced it makes sense for clangd's *primary* use cases.

For example, our default policy gives different answers for code in different paths, which has some desirable properties (e.g. once you stop working on a project, its index files can be removed in an obvious way without disturbing other projects).
A mechanism that allows customization but has its own limitations can add confusion without actually solving many more people's problems.
And generally we're trying to phase out use of global command line flags in favor of config files while carefully limiting the amount of options users need to understand.

Given that there are some workarounds available (compile-commands dir, making the .cache directory a symlink, maybe even using clangd-indexer instead depending on your purpose) I think we probably shouldn't add this option, or should at least defer it until we have more info on what kind of customization people need while using clangd together with an editor.

crr0004 abandoned this revision.Jun 1 2021, 4:17 PM

Whoops. Hit close without adding this comment.

Okay thank you for that @sammccall and @kadirect. Ultimately shared this patch was I found it useful but wasn't sure if it would fit with the project.

Is there somewhere I can read about project direction/decisions? Like the stepping away from global config on the cli. Or is there a backlog of stuff that has been planned and is waiting for someone to pickup?

More than happy to continue to help with reviews, bugs and other day to day stuff.