Skip to content

Commit 3e05710

Browse files
committed
Auto merge of rust-lang#117148 - dtolnay:sinceversion, r=cjgillot
Store #[stable] attribute's `since` value in structured form Followup to rust-lang#116773 (review). Prior to this PR, if you wrote an improper `since` version in a `stable` attribute, such as `#[stable(feature = "foo", since = "wat.0")]`, rustc would emit a diagnostic saying **_'since' must be a Rust version number, such as "1.31.0"_** and then throw out the whole `stable` attribute as if it weren't there. This strategy had 2 problems, both fixed in this PR: 1. If there was also a `#[deprecated]` attribute on the same item, rustc would want to enforce that the stabilization version is older than the deprecation version. This involved reparsing the `stable` attribute's `since` version, with a diagnostic **_invalid stability version found_** if it failed to parse. Of course this diagnostic was unreachable because an invalid `since` version would have already caused the `stable` attribute to be thrown out. This PR deletes that unreachable diagnostic. 2. By throwing out the `stable` attribute when `since` is invalid, you'd end up with a second diagnostic saying **_function has missing stability attribute_** even though your function is not missing a stability attribute. This PR preserves the `stable` attribute even when `since` cannot be parsed, avoiding the misleading second diagnostic. Followups I plan to try next: - Do the same for the `since` value of `#[deprecated]`. - See whether it makes sense to also preserve `stable` and/or `unstable` attributes when they contain an invalid `feature`. What redundant/misleading diagnostics can this eliminate? What problems arise from not having a usable feature name for some API, in the situation that we're already failing compilation, so not concerned about anything that happens in downstream code?
2 parents d914890 + 76d7af0 commit 3e05710

File tree

1 file changed

+18
-12
lines changed

1 file changed

+18
-12
lines changed

clippy_utils/src/qualify_min_const_fn.rs

+18-12
Original file line numberDiff line numberDiff line change
@@ -5,6 +5,7 @@
55

66
use crate::msrvs::Msrv;
77
use hir::LangItem;
8+
use rustc_attr::{Since, CURRENT_RUSTC_VERSION};
89
use rustc_const_eval::transform::check_consts::ConstCx;
910
use rustc_hir as hir;
1011
use rustc_hir::def_id::DefId;
@@ -370,19 +371,24 @@ fn is_const_fn(tcx: TyCtxt<'_>, def_id: DefId, msrv: &Msrv) -> bool {
370371
// function could be removed if `rustc` provided a MSRV-aware version of `is_const_fn`.
371372
// as a part of an unimplemented MSRV check https://github.com/rust-lang/rust/issues/65262.
372373

373-
// HACK(nilstrieb): CURRENT_RUSTC_VERSION can return versions like 1.66.0-dev. `rustc-semver`
374-
// doesn't accept the `-dev` version number so we have to strip it off.
375-
let short_version = since
376-
.as_str()
377-
.split('-')
378-
.next()
379-
.expect("rustc_attr::StabilityLevel::Stable::since` is empty");
374+
let const_stab_rust_version = match since {
375+
Since::Version(version) => RustcVersion::new(
376+
u32::from(version.major),
377+
u32::from(version.minor),
378+
u32::from(version.patch),
379+
),
380+
Since::Current => {
381+
// HACK(nilstrieb): CURRENT_RUSTC_VERSION can return versions like 1.66.0-dev.
382+
// `rustc-semver` doesn't accept the `-dev` version number so we have to strip it off.
383+
let short_version = CURRENT_RUSTC_VERSION.split('-').next().unwrap();
384+
RustcVersion::parse(short_version).unwrap_or_else(|err| {
385+
panic!("`rustc_attr::StabilityLevel::Stable::since` is ill-formatted: `{CURRENT_RUSTC_VERSION}`, {err:?}")
386+
})
387+
},
388+
Since::Err => return false,
389+
};
380390

381-
let since = rustc_span::Symbol::intern(short_version);
382-
383-
msrv.meets(RustcVersion::parse(since.as_str()).unwrap_or_else(|err| {
384-
panic!("`rustc_attr::StabilityLevel::Stable::since` is ill-formatted: `{since}`, {err:?}")
385-
}))
391+
msrv.meets(const_stab_rust_version)
386392
} else {
387393
// Unstable const fn with the feature enabled.
388394
msrv.current().is_none()

0 commit comments

Comments
 (0)