Allow clippy-driver maybe?

[yaahc]

The Dream

So I'm playing around and testing how hard it would be to integrate clippy-driver into cargo build and cargo check by exporting RUSTC=clippy-driver. For most crates this works fine and it builds and outputs just as if it were rustc but also you get clippy warnings.

The Problem

Turns out libc's build.rs file doesn't like clippy very much, and when you try to build you get the following error.

Which seems to be caused by this section of the build.rs file

https://github.com/rust-lang/libc/blob/master/build.rs#L87-L96

The Proposal

I'm not sure if this is crazy talk but I'd like it if libc could play nicely with clippy-driver. I know old versions will still miscompile so iunno how important helpful fixing this in libc is, but I figured I'd report it anyways

I'm not an expert but I think using rustc -vV instead of rustc --version might be better and more consistent with how the rest of the ecosystem gets version info from the compiler (thinking about cargo and sccache here). Here is the comparable outputs of those two invocations on rustc and clippy-driver

[yaahc]

One suggestion for fixing this in a backwards compatible(??) way would be to adjust the output of clippy-driver --version to output something like

rustc 1.??.0 + clippy 0.0.??

Lets just hope to god that nobody is depending directly on the output of clippy-driver --version

cc @Manishearth

[KodrAus]

Hmm, it looks like serde uses pretty much the same approach, libraries depending on if_rust_version or version_check will possibly report an incorrect version (using clippy's instead of rustc's), and those using rustc-version should work.

Making clippy-driver's output support existing version parsers would be pragmatic, but it seems like trying to standardize around -vV would be more robust.

[gnzlbg]

I'm not an expert but I think using rustc -vV

Sure, we could try doing that. PRs welcome :)