You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
let(suggestion, span) = if msrv.meets(cx, msrvs::RAW_REF_OP){
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:
I assume this could work with a list of unstable features (or perhaps a list of lints that would ignore the msrv behavior).
In any case, if it is tricky to do this, then I guess we could for the time being avoid using the msrv field -- some notes at Rust-for-Linux/linux#1152 (comment). Eventually we will not use unstable features like today, so it is not a critical feature, but it would be nice to be able to use unstable features without having to lose the msrv feature.
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: