rust-analyzer: fix root pattern for multi-crate projects

[mjlbach]

Closes #310

This will prefer git directory > rust-project.json > cargo.toml

[mjlbach]

@csmoe @geigerzaehler I believe this is the correct thing to do. Can you forsee any scenarios where it wouldn't be?

[csmoe]

I'm okay with this 👍

[mjlbach]

I'm like 99% sure this is what people really want haha, so hopefully it didn't/doesn't break anything for anyone.

[lithammer]

I'm like 99% sure this is what people really want haha, so hopefully it didn't/doesn't break anything for anyone.

I could easily think of a scenario where a company is using a polyglot monorepo where this wouldn't make sense. Either because the sub-projects aren't related, or because there's nothing useful in the root of the repo (e.g. just folders and a readme).

[mjlbach]

I could easily think of a scenario where a company is using a polyglot monorepo where this wouldn't make sense. Either because the sub-projects aren't related, or because there's nothing useful in the root of the repo (e.g. just folders and a readme).

This is the main counter example. Unfortunately, I don't think there is an automated way that will support both options, and this covers the more common scenario of having multiple crate submodules. I added a note in the wiki on project local configuration, so you can just hardcode your root_dir for a complex polyglot project for each language server (as you'd probably have to).

If enough people complain, I can switch it back, but it's also easy enough for them to override.

[csmoe]

I know nothing about lua, can we check whether the Cargo.toml contains a workspace section?

[workspace]
members= [ ... ]

cc https://doc.rust-lang.org/cargo/reference/workspaces.html

[lithammer]

I wonder if we can leverage the cargo command itself to figure out the workspace root? Supposedly there's a workspace_root field in the cargo metadata output (see rust-lang/cargo#4938).

$ cargo metadata --format-version 1 | jq -r .workspace_root

[mjlbach]

Will workspace_root always point to the correct top level workspace for multi-crate projects? We could parse the file in lua pretty easily and fallback to the current (albeit slightly flawed) schema

[lithammer]

Seems like it does. I just tested on the ripgrep repo which contains a handful of sub-crates.

$ pwd
/Users/peter/Workspace/tmp/ripgrep
$ find . -name Cargo.toml
./Cargo.toml
./crates/searcher/Cargo.toml
./crates/globset/Cargo.toml
./crates/ignore/Cargo.toml
./crates/printer/Cargo.toml
./crates/cli/Cargo.toml
./crates/regex/Cargo.toml
./crates/matcher/Cargo.toml
./crates/grep/Cargo.toml
./crates/pcre2/Cargo.toml
$ cd crates/grep
$ cargo metadata --format-version 1 | jq -r .workspace_root
  Downloaded encoding_rs_io v0.1.7
  Downloaded pcre2 v0.2.3
  Downloaded pcre2-sys v0.2.5
  Downloaded crossbeam-channel v0.5.0
  Downloaded bytecount v0.6.0
  Downloaded 5 crates (2.3 MB) in 1.08s (largest was `pcre2-sys` at 2.2 MB)
  Downloaded jemalloc-sys v0.3.2
  Downloaded jemallocator v0.3.2
  Downloaded 2 crates (1.4 MB) in 0.43s (largest was `jemalloc-sys` at 1.3 MB)
/Users/peter/Workspace/tmp/ripgrep

I guess the "Downloaded" stuff is a bit unfortunate...

[csmoe]

Will workspace_root always point to the correct top level workspace for multi-crate projects?

yes, multiple workspace roots in the same workspace is not allowed in cargo, in other words, there will be only one workspace_root in a project.

[lithammer]

This makes me wonder though. If we don't send a root dir at all, will rust-analyzer figure this out automatically for us? Seems like it would be better fit to do this.

[csmoe]

@lithammer ra seems already do that. cc https://github.com/rust-analyzer/rust-analyzer/blob/4ddf075673c4a8e3b5b0be5a2f085cdefe3993ef/crates/project_model/src/workspace.rs#L1

[mjlbach]

Given we can performantly parse a json, we should be able to read the metadata from cargo. We rely on knowing the root directory internally for other things (keeping track of root_dir for workspace folder management, and for some upcoming features around that I'm working on), so I think it's best we compute it ourselves.

PR incoming.