-
Notifications
You must be signed in to change notification settings - Fork 1.7k
feature request: #[feature]
awareness in MSRV-gated lints
#14477
New issue
Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? # to your account
Comments
I assume this could work with a list of unstable features (or perhaps a list of lints that would ignore the In any case, if it is tricky to do this, then I guess we could for the time being avoid using the
To clarify, we also use a few others in https://github.com/Rust-for-Linux/linux/blob/edc5e6e019c99b529b3d1f2801d5cce9924ae79b/rust/kernel/lib.rs#L16-L42 (and for |
We can check for enabled features for features that are probably stable indeed. We already do that, for example in the Is that what you need? If this is, don't hesitate to request such additions on a lint+feature basis, as a feature request (ah ah). |
Yeah, so e.g. for us For Linux we don't have many cases -- we are now fairly close to stable (I updated the link above since there was a cleanup that makes it more readable). Doing it for at least ( Thanks! |
Some lints, such as
borrow_as_ptr
have conditional behavior based on MSRV:rust-clippy/clippy_lints/src/casts/borrow_as_ptr.rs
Line 31 in fe4dd5b
In Rust-for-Linux, this is not sufficient because we enable a number of unstable features when we are reasonably confident their behavior won't change before stabilization, or because we know they have been stabilized without API change in a version that exceeds our configured MSRV.
It would be extremely helpful if these MSRV checks could be taught to also respect
#[feature]
attributes that enable unstable features ahead of the MSRV having been met. This is especially tricky when API has actually changed between the configured MSRV and the feature's actual stabilization.The text was updated successfully, but these errors were encountered: