clippy-service
clippy-service copied to clipboard
Support custom feature configuration
Also tested it, it reports warning in a file guarded by
#![cfg_attr(feature="clippy", allow(float_cmp))]Clippy is often used with a
clippy,dev,nightly,testingor whatever feature in the wild, does the service have a way to compile with a given feature?
And to quote myself:
@Manishearth , @mcarton could you elaborate why the
conf_attrthings doesn't work in the rustc approach I am currently taking? And maybe what we can do about that? Is this because the we don't pass that config? I was thinking of allowing some customization of the rustc command via a.clippy.tomlin the same folder. There the owner could configure they want "feature" xyz, would that solve the issue?
Note that Clippy might get a Clippy.toml file by itself (see https://github.com/Manishearth/rust-clippy/pull/698). Adding another .clippy.toml file would be confusing at best. If this is the way we choose, we could just add the conf there.
@mcarton: good point. Will that config contain a way to configure said features from there?
No, Clippy cannot change the features itself.
Another option might be to include it in the URL, along with the repo and branch.
At the same time, we could allow a [service] clippy-feature="nightly" key in the toml. Clippy itself can ignore it, but clippy-service reads it. No reason we can't share a conf file :smile:
No reason we can't share a conf file
Of course, but with the current PR any unknown key is an error. Should I just white-list [service] (but then what about other tools?) or ignore all unknown keys (which means eg. spelling mistake in the conf file will be hard to notice).
Nah, just whitelist [service]. Or we'll call it [third-party] or [external]
Ok then, I’ve white-listed third-party, I preferred that name.
Well, I wait for https://github.com/Manishearth/rust-clippy/pull/698 to be merged then. After that I will tackle this as part of the config-file milestone!
https://github.com/Manishearth/rust-clippy/pull/698 has been merged. Any update on this?
@indiv0 no work on this yet (from my side), but I am accepting Pull-Requests :-) !