Rust: Support for cargo invocations.

[JohnScience]

Rust developers rarely directly interact with rustc. Most of the time, we build/run our code via cargo build, cargo run, or cargo test.

[camelid]

You can use cwhy on cargo invocations with the following syntax (replacing build with run, test, etc.):

$ `cwhy --wrapper --wrapper-compiler=cargo` build

[emeryberger]

Updated Rust instructions (removed rustc, let me know if that should be restored). Thanks, @camelid and @JohnScience !

[nicovank]

Hmmm, I think this wraps cargo itself, not the compiler, hence the exact same behavior as cargo build |& cwhy. The wrapper should only wrap rustc. If cargo outputs other warnings prior to error (e.g. for files where there is otherwise no errors), or changes directory, our prompt may be worse. The goal of the wrapper mode is to strictly replace the compiler.

Cargo seems to respect the RUSTC environment variable, I think we should recommend this instead, but when I tried it some other error occurred. I can look into after this weekend if needed.

[camelid]

@nicovank I'm guessing this is the error you encountered:

$ RUSTC=`cwhy --wrapper --wrapper-compiler=rustc` cargo build
error: `rustc -vV` didn't have a line for `host:`, got:

$

Wrapping rustc in this way seems like it could be quite fragile since I believe cargo's interactions with rustc are considered unstable. (E.g. in this case, it's asking rustc its version first.) I'm a bit confused about why having cargo invoke the cwhy-wrapped rustc would be better at all. In particular, a Rust crate is considered comparable to a single C file since the whole crate is compiled as one unit. So cargo invokes rustc on the entire crate, not files one-by-one.

I think it would probably be better to just filter out the warnings from the cargo output before sending it to GPT. Another option is to use Rust's JSON error format which would allow detailed manipulations to improve the prompt.

[nicovank]

I'm not familiar with Rust's compilation system. I was under the impression that cargo was more or less Maven or Buck but guess not. Thanks for clarifying 👍.

I like the idea of using JSON output. I would like at some point to have smarter error parsing, possibly language specific: Rust could use this JSON error format, I know Clang has SARIF for some diagnostics (all?). It would be more robust than current regular expressions. Then add a mode option to CWhy (e.g. --mode rust or --mode clang), and of course try to auto-detect mode.

[camelid]

Yeah, basically when you run rustc foo.rs, it treats foo.rs as the root file of a crate named foo. Then (if I'm remembering correctly) any time it encounters mod bar; statements, it goes and loads a file named bar.rs and compiles it within the context of the foo crate (with specific behavior around how it finds the files that I'm not sure of).