Inline errors not shown for multi-crate project with custom build script

[RalfJung]

I am trying to get vscode to work properly with Miri. The tricky part is that Miri consists of two (independent) crates, but is not a workspace because that wouldn't work with it also being part of the rustc workspace. So (and also for other reasons) I have a ./miri script somewhat similar to ./x.py. I configured vscode to use that script:

    "rust-analyzer.checkOnSave.overrideCommand": [
        "./miri",
        "check",
        "--message-format=json",
    ],

When I run this on the command-line, it works fine -- at least there is lots of JSON and some of it looks like the error message I am expecting. But in vscode, it doesn't show errors for cargo-miri (the crate that is in a subfolder). It does show errors for the "root" crate -- almost as if it would ignore my command?
I am not sure how to debug this. I found a thing called "extension debug log folder" and in there I found this

[ERROR rust_analyzer::main_loop] File with cargo diagnostic not found in VFS: file not found: /home/r/src/rust/miri/bin.rs

but I am not sure if that has any significance. That folder indeed does not exist, there's a cargo-miri subfolder that is missing -- but the JSON is giving the absolute path correctly:

{"reason":"compiler-message","package_id":"cargo-miri 0.1.0 (path+file:///home/r/src/rust/miri/cargo-miri)","target":{"kind":["bin"],"crate_types":["bin"],"name":"cargo-miri","src_path":"/home/r/src/rust/miri/cargo-miri/bin.rs","edition":"2018","doctest":false,"test":false},"message":{"rendered":"For more information about an error, try `rustc --explain E0069`.\n","children":[],"code":null,"level":"failure-note","message":"For more information about an error, try `rustc --explain E0069`.","spans":[]}}

Any idea why vscode does not show inline errors for cargo-miri?

I realize this is a strange setup, but it is no more strange than rustc's x.py so I am trying to figure out why it does not work.^^

[bjorn3]

Try setting rust-analyzer.linkedProjects to an array with the paths of all Cargo.toml files (["./Cargo.toml", "./cargo-miri/Cargo.toml"])

[RalfJung]

Interesting option. However, just setting that does not change anything.

Isn't there a debug log of how it invokes the check-on-save command and if that was executing properly? When I save, the "cargo check" label doesn't appear at all (or it disappears very quickly), so I am not sure it is even running the right thing.

[RalfJung]

Oh, in the last few minutes it decided that my language server was outdated. (That message wasn't there yet 30min ago and I didn't notice it popping up.) Let's see if that changes anything...

No, doesn't seem to help either.

[RalfJung]

Strangely, even if I remove my custom build script but keep linkedProjects, it still does not show any inline errors:

// Place your settings in this file to overwrite default and user settings.
{
    "rust-analyzer.rustfmt.extraArgs": [
        "+nightly"
    ],
    "rust-analyzer.linkedProjects": ["./Cargo.toml", "./cargo-miri/Cargo.toml"]
}

So maybe the problem is not with my build script but with with the extension's handling of having multiple "linked project"?

[RalfJung]

A possible factor in this might be this part of cargo-miri/Cargo.toml:

[[bin]]
name = "cargo-miri"
path = "bin.rs"
test = false # we have no unit tests
doctest = false # and no doc tests

Maybe it incorrectly interprets path as relative to the root, not relative to the Cargo.toml file?

[RalfJung]

I think this is fixed / tracked elsewhere these days:

• without an overrideCommand, it works as expected
• with overrideCommand, the actual problem is a combination of overrideCommand with a relative path (./miri/./x.py) does not work very well, and that is very hard to debug #10793 and Using --manifest-path, the filenames in error messages are relative to the manifest, not the current working directory cargo#11007: ./miri is run in different working directories; when it is run in the root, the paths in the diagnostics are relative to another directory so RA does not understand them; when it is run inside cargo-miri, ./miri simply does not exist so no errors are shown.