Make rust_clippy providers match rustfmt_test

[0xAda]

This fixes rust_clippy failing on shared and static libraries because does not have mandatory providers: 'CrateInfo'

[google-cla]

Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

View this failed invocation of the CLA check for more information.

For the most up to date status, view the checks section at the bottom of the pull request.

[UebelAndre]

Thanks! Could you also add tests for this in https://github.com/bazelbuild/rules_rust/tree/0.17.0/test/clippy ?

Similar to https://github.com/bazelbuild/rules_rust/blob/0.17.0/test/rustfmt

[UebelAndre]

@0x4da friendly ping 😄

[0xAda]

@UebelAndre I've added tests in the same style as the existing clippy tests, but I'm not sure if that is the best way of doing it.

In the example of the rustfmt tests, everything is done on the source of a binary, thats currently not the case for clippy (and cant be if we're testing proc macros), I decided against using a loop over variants like in rustfmt, as I couldn't see a nice way to deal with special casing binary, proc_macro and test.

The rustfmt example also doesn't quite map perfectly because rustfmt rules run as a test, whereas clippy rules run as a build step, I'm not sure I understand the reasoning behind this, it feels like it should be testy to me, but I'm unaware of the reasoning behind the current way of doing things. I also have the same question of the clippy test, is there a reason thats a sh_binary instead of a sh_test?

[UebelAndre]

I think the thing that matters most is that we have clippy running against rust_shared_library in some CI job. What you have looks good enough to me :)