Add compile mode for cargo check about cargo2nix HOT 5 CLOSED

This task could be made easier with #118, given that --message-format=json happens to include a list of filenames (in this case, .rmeta artifacts when using cargo check) belonging to the current crate. We could leverage this flag to glean what artifacts need to be copied in the Nix store on cargo check or cargo clippy.

Note that the .d files aren't listed with --message-format=json, and deleting them doesn't seem to invalidate the cache of cargo check nor affect the final result, indicating that they are probably safe to ignore.

from cargo2nix.

I think this feature would require a sizeable refactor of overlay/mkcrate.nix because cargo check is so different from cargo {build,test}. In the latter, we only care about .{rlib,a,so,dylib} files, while in the former we apparently only care about .rmeta files. This means that we can't reuse the linking logic in overlay/utils.sh; we'll need to write it nearly from scratch specifically for cargo check.

AFAIK, we can't wrap rustc and use command-line flags to point to Nix store paths of .rmeta files, so we may need to instead create a target/deps directory, symlink-farm all the dependencies' .rmeta files into it, and then pick out all the non-symlink files created and copy them to $out somewhere. This is so radically different from the other two compile modes, in fact, that I'm not sure how to approach this task without turning mkcrate.nix into a tangled mess.

from cargo2nix.

I ran the check --release on RustAnalyzer. Significantly more diverse outputs in the artifacts than just .d and .rmeta

Aside, since rust check doesn't need to link or emit binary, is it even benefiting from cargo2nix's native deps? I would like to constrain the role so that cargo2nix is doing maximum utility but with only strictly necessary second-system overhead

from cargo2nix.

@psionic-k It depends on the particular crate. If a crate provides a build.rs that performs codegen, it might run at cargo check time. As such, we have to be prepared for the possibility that the build.rs might call out to a native dep at any time, even during cargo check. Apparently, there is a desire upstream to indicate to build scripts whether a crate is "building" or "checking" and adjust the work done as a result, but this doesn't seem to have landed yet (rust-lang/cargo#4001).

from cargo2nix.

See reasoning in #92 for not blocking, but also not pursuing more support for non-output Nix derivations

from cargo2nix.