Correctly handle stability of #[diagnostic] attributes

This commit changes the way we treat the stability of attributes in the
`#[diagnostic]` namespace. Instead of relaying on ad-hoc checks to
ensure at call side that a certain attribute is really usable at that
location it centralises the logic to one place. For diagnostic
attributes comming from other crates it just skips serializing
attributes that are not stable and that do not have the corresponding
feature enabled. For attributes from the current crate we can just use
the feature information provided by `TyCtx`.
This commit is contained in:
Georg Semmler 2024-09-06 18:47:22 +02:00
parent 59d4114b2d
commit 717a11788d
No known key found for this signature in database
GPG key ID: A87BCEE5205CE489
5 changed files with 51 additions and 6 deletions

View file

@ -1186,3 +1186,11 @@ pub static BUILTIN_ATTRIBUTE_MAP: LazyLock<FxHashMap<Symbol, &BuiltinAttribute>>
}
map
});
pub fn is_stable_diagnostic_attribute(sym: Symbol, features: &Features) -> bool {
match sym {
sym::on_unimplemented => true,
sym::do_not_recommend => features.do_not_recommend,
_ => false,
}
}