@GrahamcOfBorg build rustPackages.clippy

Currently debugging:

cargo clippy -- -D clippy::all 

error: failed to run `rustc` to learn about target-specific information

Caused by:
  process didn't exit successfully: `/nix/store/69hb0j56ds87l8xmijm0cg2ngdkc73dm-clippy-1.36.0/bin/clippy-driver /nix/store/yly9ihpxm0w19p4hdmkx6nrpja18kj7h-rustc-1.36.0/bin/rustc - --crate-name ___ --print=file-names -W rust-2018-idioms -D warnings --crate-type bin --crate-type rlib --crate-type dylib --crate-type cdylib --crate-type staticlib --crate-type proc-macro` (signal: 6, SIGABRT: process abort signal)
--- stderr
dyld: Library not loaded: @rpath/librustc_driver-ec53b32ba44677b6.dylib
  Referenced from: /nix/store/69hb0j56ds87l8xmijm0cg2ngdkc73dm-clippy-1.36.0/bin/clippy-driver
  Reason: image not found

I fixed the @rpath/librustc_driver-ec53b32ba44677b6.dylib issue by depending on rustc.

Could we build rustfmt in the same way (i.e. from the rustc source tarball)?

Could we build rustfmt in the same way (i.e. from the rustc source tarball)?

I suspect so.

I fixed the @rpath/librustc_driver-ec53b32ba44677b6.dylib issue by depending on rustc.

Somehow this error came back in a local build so don't merge yet.

Could we build rustfmt in the same way (i.e. from the rustc source tarball)?

I suspect so.

I actually quite like the idea to build it from the rust tarball since clippy is closely linked to rustc and this way we can ensure it will be in sync.

I fixed the @rpath/librustc_driver-ec53b32ba44677b6.dylib issue by depending on rustc.

Somehow this error came back in a local build so don't merge yet.

The following fixed the problem:

  preFixup = stdenv.lib.optionalString stdenv.isDarwin ''
    install_name_tool -add_rpath "${rustc}/lib" $out/bin/clippy-driver
  '';

And clippy works on my project. This is now ready for review.

@GrahamcOfBorg build rustPackages.clippy