Allow loading plugins into dependencies

[huonw]

This would essentially just be exposing the functionality of rustc -Z extra-plugins=.... The use case I imagine is that programmers can force dependencies to satisfy specific lint requirements (e.g. to outlaw common bad patterns, have stricter requirements around unsafe etc.).

See also http://stackoverflow.com/q/30047179/1256624

[llogiq]

I haven't read enough of the cargo source, but I gather it would be most useful to add a config parameter to profiles, e.g.

[profile.dev]
extra-plugins=clippy, tenacious

[profile.test]
extra-plugins=clippy, tenacious

So the Profile struct would need to add a new field plugins : Option<String> which it would get from the TomlProfile, yes?

[alexcrichton]

Cargo is currently very specifically avoiding all -Z flags, so we wouldn't want to just pass that through, and I'd also be a little worried about modifying how dependencies' code is being compiled, but in theory I can see where this may be useful.

[llogiq]

It's not only theoretically useful – I very practically want to a) lint my code on test and b) test my lints on other code. And I'd prefer to use a cargo option instead of putting #![plugin(clippy)] in front of every file.

@alexcrichton I'd like to hear a bit more about your objection to this feature. Is it that you fear misuse (we obviously should check the supplied plugin list to see if they are available, so that would rule out tricks to bring in other flags here)? Or is there another rationale that I haven't heard of yet?

[Manishearth]

I really think that the toplevel package and/or .cargo config should be able to provide any and all flags to rustc

I understand the objection when it's being done to a lower package -- it breaks stability -- but as a developer it would be nice to be able to do it at the top level to either get some extra control over the build, or load extra features. Currently we have to do cargo build -v and copy the invocation to do simple things like tracking time-passes or getting the expanded source. Permanent additions to the build, like linker args, need to be done via hacks like fake link scripts. I don't see why the toplevel package can't modify the rustc invocation anyway it wants.

[llogiq]

Exactly my sentiment. I'm also fine with restricting the extra flags to the top-level package. However, that looks a tad more complex than just adding an Option<String> to Profile.

[llogiq]

A somewhat related problem I recently had: If a dependency (such as compiletest.rs) declares #![deny(deprecate)] it will make the build fail once a new version arrives that deprecates any of the features it uses. This actually happened to me yesterday.

Note that my RFC PR would make this a non-problem, but it may still be useful to have a cargo-based workaround in the meantime.

[ticki]

👍

[alexcrichton]

Cargo currently doesn't reexport any unstable functionality of the compiler (as Cargo doesn't have feature staging like Rust does). For this reason I don't think Cargo will support this until it's either stabilized in the compiler or you can pass arbitrary flags down (which you can do with cargo rustc currently).

As a result this isn't totally actionable today (until upstream support is stabilized), so I'm going to close this.

[Manishearth]

You can't. cargo rustc passes flags only to the crate being compiled. I don't know any variant which passes flags all the way down to deps.