Nathan Ridge

If RustDT ends up using rustw as suggested in https://github.com/RustDT/RustDT/issues/128#issuecomment-239818190, would that provide the desired fully resolved semantic information?

It looks like it's cargo that's creating the git repository, and this can be controlled by passing `--vcs hg` or `--vcs none` as arguments to `cargo init`. Perhaps RustDT should...

So in the future RustDT will use rustw?

> > So in the future RustDT will use rustw? > > Seems likely, but it's just an idea at the moment. Another idea, which I've just discovered, might be...

@ToBoMi I don't think use of clangd's "external index" feature is needed to solve the problem you're describing; letting the dependent libraries be indexed by clangd's background indexer should be...

>> if the library has its own compile_commands.json > > They do not have its own compile_commands.json. The library source files need to be listed in **some** `compile_commands.json` for them...

Don't you need a `compile_commands.json` to create an external index, too?

How does `clangd-indexer` know which library source files to index if they are not listed in the `compile_commands.json`?

You're probably aware of this, but just for completeness: you can of course manually download any version from https://github.com/clangd/clangd/releases and put it in your PATH or point `clangd.path` to it.

This crash no longer occurs with clangd 17.