The #[panic_handler] attribute can be applied to non-functions #54997
Conversation
This commit extends the existing lang items functionality to assert that the `#[lang_item]` attribute is only found on the appropriate item for any given lang item. That is, language items representing traits must only ever have their corresponding attribute placed on a trait, for example.
rust-highfive
added
the
S-waiting-on-review
|
@bors r+ This looks good to me. |
|
📌 Commit 2ecce7c has been approved by |
bors
added
S-waiting-on-bors
| PanicImplLangItem, "panic_impl", panic_impl; | ||
| PanicFnLangItem, "panic", panic_fn, Target::Fn; | ||
| PanicBoundsCheckFnLangItem, "panic_bounds_check", panic_bounds_check_fn, Target::Fn; | ||
| PanicInfoLangItem, "panic_info", panic_info, Target::Struct; |
There was a problem hiding this comment.
In the future there might be a language item that could possibly be some sort of type definition, not specifically a struct.
This is especially notable here. panic_info in no_core could easily be defined to be an enum as well for example – in fact, the only reason this is a language item is to facilitate type-checking the panic_impl function.
Yet, I do not see a nice way out here, and since language items are not stable anyway it seems fine to keep it restrictive for now.
There was a problem hiding this comment.
I think this could be extended to have a Target::Any that allows the attribute to be applied to anything, as was the behaviour before this PR.
Alternatively, the definition of Target could be changed to a u32 and have each bit represent a variant (similar to AdtFlags) and then the language item definitions could | together these “variants” to indicate that the attribute could be applied to either construct.
I agree that, for the moment, the simplest solution would be to keep this more restrictive approach and change if necessary.
The #[panic_handler] attribute can be applied to non-functions Fixes #54896. This commit extends the existing lang items functionality to assert that the `#[lang_item]` attribute is only found on the appropriate item for any given lang item. That is, language items representing traits must only ever have their corresponding attribute placed on a trait, for example. r? @nagisa
|
☀️ Test successful - status-appveyor, status-travis |
Fixes #54896.
This commit extends the existing lang items functionality to assert
that the
#[lang_item]attribute is only found on the appropriate itemfor any given lang item. That is, language items representing traits
must only ever have their corresponding attribute placed on a trait, for
example.
r? @nagisa