add diagnostics subcommand to rust-analyzer CLI

[JoshMcguigan]

This PR adds a diagnostics subcommand to the rust-analyzer CLI. The intent is to detect all diagnostics on a workspace. It returns a non-zero status code if any error diagnostics are detected. Ideally I'd like to run this in CI against the rust analyzer project as a guard against false positives.

$ cargo run --release --bin rust-analyzer -- diagnostics .

Questions for reviewers:

1. Is this the proper way to get all diagnostics for a workspace? It seems there are at least a few ways this can be done, and I'm not sure if this is the most appropriate mechanism to do this.
2. It currently prints out the relative file path as it is collecting diagnostics, but it doesn't print the crate name. Since the file name is relative to the crate there can be repeated names, so it would be nice to print some identifier for the crate as well, but it wasn't clear to me how best to accomplish this.

[flodiebold]

it would be nice to print some identifier for the crate as well, but it wasn't clear to me how best to accomplish this.

We have a display_name in CrateData nowadays for this purpose. Though it may be nicer to have a file path from the source root for generating full file names 🤔 In any case, we can fix this in a separate PR, analysis-stats has the same problem.

[flodiebold]

Ideally I'd like to run this in CI against the rust analyzer project as a guard against false positives.

I'd be a bit wary about that at this stage, we don't want random PRs to break because they added new code that happens to have a false positive 😬 (Apart from the impact on build times...)

Since I don't have a much better approach for getting all diagnostics, I'd be fine with merging this one for now, considering this is just a debug tool anyway at the moment.

bors d+

[bors]

✌️ JoshMcguigan can now approve this pull request. To approve and merge a pull request, simply reply with bors r+. More detailed instructions are available here.

[JoshMcguigan]

@flodiebold I've changed this quite a bit in my most recent commit based on your suggestions. If you don't mind I'd prefer you take another quick look before I merge.

[JoshMcguigan]

I'd be a bit wary about that at this stage, we don't want random PRs to break because they added new code that happens to have a false positive grimacing (Apart from the impact on build times...)

This is a good point. My thought was this would run nightly, similar to analysis-stats.

[JoshMcguigan]

bors r+

[bors]

Build succeeded:

• Rust (ubuntu-latest)
• Rust (windows-latest)
• TypeScript
• Rust (macos-latest)

[matklad]

Super minor point, but I prefer spelling this as format_err instead (the same macro is exported under two aliases).