No problems are shown for non-Cargo projects

[dwlsalmeida]

Hi there,

No problems are shown when using RA for non-Cargo projects in VScode. My linkedProjects points to a valid rust-project.json file, and other features are working (hints, code completion, etc).

I tried debugging RA and apparently CargoActor::run expects the command to output some kind of JSON as per the documentation. The problem is that my project is being built by Meson/Ninja, and thus, whatever JSON is expected is simply not produced by these tools.

Is this expected behavior? I was under the impression that the whole point of rust-project.json was to cater to non-Cargo projects and that RA would manage to invoke rustc and then parse whatever compilation errors on its own.

[davidbarsky]

This is expected behavior, yes. rust-project.json is only responsible for providing rust-analyzer an index of the crate graph, it does not tell rust-analyzer how to build your project.

[dwlsalmeida]

I humbly suggest to clarify this in the docs, I spent quite a bit of time thinking the issue was on my end.

On another note, is there any way I can make this work? Lots of people using Meson, probably, so maybe there's some workaround already in place?

[xclaesse]

it does not tell rust-analyzer how to build your project.

Could rust-analyser use compile_commands.json for that?

[xclaesse]

Example of what you get in that file when using Meson to build Mesa rust code:

  {
    "directory": "/home/xclaesse/programmation/mesa/builddir",
    "command": "rustc -C linker=cc --color=always -C debug-assertions=yes -C overflow-checks=no --crate-type rlib -C opt-level=2 -g --crate-name rusticl_opencl_gen --emit dep-info=src/gallium/frontends/rusticl/rusticl_opencl_gen.d --emit link=src/gallium/frontends/rusticl/librusticl_opencl_gen.rlib --out-dir src/gallium/frontends/rusticl/librusticl_opencl_gen.rlib.p -C metadata=b863b06@@rusticl_opencl_gen@sta -Aclippy::all -Aunused_unsafe -Anon_camel_case_types -Anon_snake_case -Anon_upper_case_globals src/gallium/frontends/rusticl/rusticl_opencl_bindings.rs",
    "file": "src/gallium/frontends/rusticl/rusticl_opencl_bindings.rs",
    "output": "src/gallium/frontends/rusticl/librusticl_opencl_gen.rlib"
  },

[dwlsalmeida]

There is also the issue of whether rustc can itself emit JSON or if this is something done by Cargo

[xclaesse]

Pretty sure it can: https://doc.rust-lang.org/rustc/json.html, unless that's not what RA needs?

[davidbarsky]

Sorry, was (correctly) yanked away from the computer by my spouse over the holiday.

I humbly suggest to clarify this in the docs, I spent quite a bit of time thinking the issue was on my end.

Probably not a bad idea.

On another note, is there any way I can make this work? Lots of people using Meson, probably, so maybe there's some workaround already in place?

I've never used Meson before, but a decent chunk of my dayjob is supporting using rust-analyzer with buck2. Depending on whether Meson requires you to specify a build target for each command or not (where buck/bazel is an example of the former and Cargo is an example of the latter), you might be able to make use of the rust-analyzer.check.overrideCommand setting (search for it on https://rust-analyzer.github.io/manual.html, as I'm unable to link to a definition item) if you're able to get Meson to emit JSON-structured diagnostics from rustc.

Could rust-analyser use compile_commands.json for that?

@xclaesse I'm assuming that you're referring clangd's compile_commands.json? I don't think it'll take that form specifically, but there might be sufficient demand for something that does a similar thing in rust-analyzer.

Pretty sure it can: https://doc.rust-lang.org/rustc/json.html, unless that's not what RA needs?

Yes, that is the output that rust-analyzer expects from the build system/compiler.

[xclaesse]

@xclaesse I'm assuming that you're referring clangd's compile_commands.json? I don't think it'll take that form specifically, but there might be sufficient demand for something that does a similar thing in rust-analyzer.

Yes, that file is created by Ninja (and thus meson, but also cmake) and is used for example by vscode C/C++ analysers. I think it would be a nice addition for rust-analyser to use the same file, it's somewhat "the standard". My understanding is it should be pretty easy to find the rustc command from that file and just append --error-format=json. Is there any info missing for RA to work that way?

https://clang.llvm.org/docs/JSONCompilationDatabase.html

[xclaesse]

Seems there is already request to support that db in buck2 as well: facebook/buck2#194.

[davidbarsky]

Yes, that file is created by Ninja (and thus meson, but also cmake) and is used for example by vscode C/C++ analysers. I think it would be a nice addition for rust-analyser to use the same file, it's somewhat "the standard".

While it is certainly the standard in C++, I don't believe it's the standard. At the risk of coming off as being afflicted with NIH, I think that any build system integration into rust-analyzer would either take the form of collaborating with a companion extension (such as a buck-companion or vscode-meson) or forcing the non-Cargo build system to emit data in a form very similar to what Cargo does ¹.

My understanding is it should be pretty easy to find the rustc command from that file and just append --error-format=json. Is there any info missing for RA to work that way?

For Meson? I don't know. If it possible to do a meson compile --error-format=json (where --error-format=json is passed to rustc), then rust-analyzer.check.overrideCommand will just work. The limiting factor, from rust-analyzer's perspective, is that the rust-project.json format deliberately doesn't encode Cargo Target-like data that would allow determining what build target needs to be invoked for a specific crate. Put differently, rust-project.json is lower level than you might otherwise expect.

In the future, Meson could emit a rust-analyzer.toml alongside a rust-project.json that configures a per-directory build override.

Seems there is already request to support that db in buck2 as well: facebook/buck2#194.

For what it's worth, my colleagues already make use of the compilation database in C++ with some FB-internal rules. The request there is to add the same functionality in the open source release, but because C++ toolchains at FB are, uh, complicated, that hasn't happened yet.

Footnotes

1. I've opened an issue to add this functionality, but I'm not fully convinced that this is the correct approach. At work, we're using https://github.com/rust-lang/rust-analyzer/pull/15476 in tandem with this CLI, but changing how we do compiler diagnostics with buck is, generally speaking, pretty easy. ↩

[xclaesse]

At the risk of coming off as being afflicted with NIH

Nothing against creating new format if it can be justified. However, it's not clear why RA cannot work that way in this case, that seems pretty easy and would give a build system independent solution. Why do you even want to go through meson compile at all when that can be avoided?

The limiting factor, from rust-analyzer's perspective, is that the rust-project.json format deliberately doesn't encode Cargo Target-like data that would allow determining what build target needs to be invoked for a specific crate

That's fine, you don't need to extend rust-project.json format. All you need to do is cross checking with compile_commands.json to find the missing information:

rust-project.json:

"root_module": "/home/xclaesse/programmation/mesa/src/gallium/frontends/rusticl/mesa/lib.rs",

compile_commands.json:

"directory": "/home/xclaesse/programmation/mesa/builddir",
"command": "rustc ...",
"file": "../src/gallium/frontends/rusticl/mesa/lib.rs",

From root_module, you find the command (you need to join "directory" and "file" for matching), append --error-format=json, job done. Get cmake and every other build system support for free.

[xclaesse]

take the form of collaborating with a companion extension (such as a buck-companion or vscode-meson)

Note that I'm a dev of vscode-meson, that's exactly why I'm trying to see how this could be done. meson itself does not support adding --error-format=json when compiling a target. I guess we could provide some wrapper script that takes both rust-project.json and compile_commands.json files and do the matching. That wrapper could then be used as rust-analyzer.check.overrideCommand. I think that it would be better done in rust-analyser vscode extension though.

[flodiebold]

We generally don't want to implement a build system into rust-analyzer (using compile commands would still involve figuring out what needs to be rebuilt in what order when things change, etc.). The whole check-on-save functionality is just a stopgap while RA doesn't emit most diagnostics natively yet. A wrapper script called from check.overrideCommand is the way to go to support other build systems with it.
We also don't want to add support for more build systems in the VSCode extension; that should be handled by companion extensions as David described.