Stream: t-compiler/rust-analyzer

Topic: Parametric Flycheck?


woody77 (Aug 20 2020 at 01:35, on Zulip):

I'm looking at enabling the flycheck with a rust-project.json setup, and I think that I could make it work (by using a custom wrapper around cargo), if I had the name of the file that was saved that triggered the flycheck. In VSCode, the tasks can receive arguments like ${fileDirname}, which is the folder that contains the source file that's in the open editor.

Something similar to the flycheck would be useful, as then I could use the source file that was changed as a trigger for finding the "right" thing to run cargo check on.

Is there any reasonable way to plumb this through?

Further, I'm not seeing the flycheck results in my file (I'm hardcoding some things in a test setup). And I think the issue is that the cargo check output is using relative paths (src/lib.rs), that aren't relative to the root of my overall workspace. I assume this breaks RA's ability to line up the errors from cargo check with the open file in the editor? (VSCode's $rustc-watch has the same issue).

matklad (Aug 20 2020 at 09:38, on Zulip):

@woody77 cargo wrapper is the wrong approach for your use-case, you need to use rust-analyzer.checkOnSave.overrideCommand.

matklad (Aug 20 2020 at 09:40, on Zulip):

Or maybe I am misundestanding what do you mean by "cargo wrapper". But you shouldn't force bazel to look like Cargo. If there's anything cargo-specific in rust-analyzer, it's a bug in rust-analyzer. overrideCommand should allow you to plug arbitrary thing instead of cargo, which, in your case, should be something like "use bazel (or is it gn?) to compile the code passing --error-format=json to rustc".

matklad (Aug 20 2020 at 09:41, on Zulip):

The question about "which changes trigger rebuild" is interesting. That's simply not implemented in rust-analyzer yet, we have a binary "there was a change" event.

woody77 (Aug 20 2020 at 16:31, on Zulip):

I wasn't very clear, sorry about that.

I'm using the overrideCommand to run a script, which currently invokes cargo check using a generated Cargo.toml file that's not in the root of the project workspace (but about 4 levels deep). From the shell, I can run the script manually, and see error output. (this is a hard-coded test).

I'm not passing -error-format=json to rustc, so that's definitely part of my problem. I'll see what that gets me.

Ideally, though, I'd like to be able to invoke just a portion of the build space (not every crate we have, since that's 1000s). What I'd like to do is tell rustc/cargo to check the crate that corresponds to the file that was just saved by VSCode.

as an example, what my script is doing right now is:
cd some/path/that/is/hardcoded && cargo check

I'd like that path to be based on the file with focus in the editor.

matklad (Aug 20 2020 at 16:32, on Zulip):

Uhu. My advice would be to remove Cargo from the equation completely, just run whatever build system you use directly

matklad (Aug 20 2020 at 16:40, on Zulip):

I'd like that path to be based on the file with focus in the editor.

Uhu... I think that needs some design, but, as a straw man, overrideCommand could contain placeholder like ${visibleFiles}, and we can thread that to flycheck.

An imoprtant design point here is that the thing shoudl be based on state and not events. Communicating "this file changed" would be brittle; Communicating "files x.rs, y.rs, z.rs are opened, go figure which commands should be run to get errors for them" should work better

woody77 (Aug 20 2020 at 18:12, on Zulip):

I'm using Cargo as it's easier to do some prototyping with than our actual build system, as the actual build system is also trying to do a lot more (in other languages as well), and so it's a much heavier process.

woody77 (Aug 21 2020 at 18:36, on Zulip):

So, with some more digging, and it looks like my flycheck script isn't being called at all (I have it writing to a file each time it's called)... But I have a complicated VSCode Remote setup (and I'm never sure how local and remote VSCode settings interract), so I'm going to simplify to a local-only setup and see what that gets me.

Last update: Jul 26 2021 at 13:45UTC