-
Notifications
You must be signed in to change notification settings - Fork 13k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Invalid derive proc macro output silently ignored #87314
Comments
Another example: This compiles fine, but should fail: use proc_macro::TokenStream;
#[proc_macro_derive(Test)]
pub fn test(_: TokenStream) -> TokenStream {
"{} ! @ # $ blåhaj % ^ &".parse().unwrap()
} use scratchpad::Test;
#[derive(Test)]
struct A;
fn main() {} |
This is caused by the proc-macro expansion code failing to check if there are any remaining tokens in the input: rust/compiler/rustc_expand/src/proc_macro.rs Lines 119 to 134 in 5c0ca08
I'm working on a fix |
@Aaron1011 #87316 already fixes this |
IIRC, this is a duplicate of some old issue. |
Yeah let's see if anything breaks. The alternative is to make it a (future_incompatible) lint instead. |
I ran into this over the past few days trying to add a new derive macro to a crate I maintain. A superfluous semicolon snuck its way into the output of the derive, causing any subsequent code to be silently dropped (from what I can tell from this comment, semicolons seem to be a more common cause for this issue). My code produced an use ::proc_macro::*;
#[proc_macro_derive(Foo)] pub
fn __(_input: TokenStream)
-> TokenStream
{
stringify!(
enum Foo {};
impl ::core::fmt::Display for Foo {
fn fmt(&self, f: &mut ::core::fmt::Formatter<'_>) -> ::core::fmt::Result {
f.write_str("Foo")
}
}
)
.parse()
.unwrap()
} (independently of the method of constructing the This confused me for a good while, because initially I wrote multiple tests for the proc macro with function-local #[test]
fn foo() {
#[derive(Foo)]
enum Bar {}
} The emitted code is valid inside method bodies (playground), which is the scope that the derive output is emitted to, so it took the help of @danielhenrymantilla to figure out the last piece after it became clear that the I would expect the compiler to produce at least a warning, especially given that the macro output compiles if you write the same code by hand (when invoked inside a |
A derive proc macro expanding to something starting with a
{
is ignored:The text was updated successfully, but these errors were encountered: