Skip to content
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

Open
m-ou-se opened this issue Jul 20, 2021 · 6 comments
Open

Invalid derive proc macro output silently ignored #87314

m-ou-se opened this issue Jul 20, 2021 · 6 comments
Assignees
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.

Comments

@m-ou-se
Copy link
Member

m-ou-se commented Jul 20, 2021

A derive proc macro expanding to something starting with a { is ignored:

use proc_macro::TokenStream;

#[proc_macro_derive(Test)]
pub fn test(_: TokenStream) -> TokenStream {
    quote::quote!(
        {}
        fn main() {}
    ).into()
}
use scratchpad::Test;

#[derive(Test)]
struct A;
error[E0601]: `main` function not found in crate `scratchpad`
 --> src/main.rs:1:1
  |
1 | / use scratchpad::Test;
2 | |
3 | | #[derive(Test)]
4 | | struct A;
  | |_________^ consider adding a `main` function to `src/main.rs`
@m-ou-se m-ou-se added A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. A-proc-macros Area: Procedural macros labels Jul 20, 2021
@m-ou-se m-ou-se self-assigned this Jul 20, 2021
@m-ou-se m-ou-se added the C-bug Category: This is a bug. label Jul 20, 2021
@m-ou-se
Copy link
Member Author

m-ou-se commented Jul 20, 2021

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() {}

@Aaron1011 Aaron1011 self-assigned this Jul 20, 2021
@Aaron1011
Copy link
Member

This is caused by the proc-macro expansion code failing to check if there are any remaining tokens in the input:

loop {
match parser.parse_item(ForceCollect::No) {
Ok(None) => break,
Ok(Some(item)) => {
if is_stmt {
items.push(Annotatable::Stmt(P(ecx.stmt_item(span, item))));
} else {
items.push(Annotatable::Item(item));
}
}
Err(mut err) => {
err.emit();
break;
}
}
}

I'm working on a fix

@jonas-schievink
Copy link
Contributor

@Aaron1011 #87316 already fixes this

@Aaron1011 Aaron1011 removed their assignment Jul 20, 2021
@petrochenkov
Copy link
Contributor

IIRC, this is a duplicate of some old issue.
Things were working like this since the original implementation of custom derives, so the fix will likely require a crater run.

@m-ou-se
Copy link
Member Author

m-ou-se commented Jul 20, 2021

Yeah let's see if anything breaks. The alternative is to make it a (future_incompatible) lint instead.

@domenicquirl
Copy link
Contributor

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 enum and an impl Trait for that enum. The following proc macro code will only emit the enum declaration and will not implement Display for Foo:

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 TokenStream, the same happens if you quote! the code)

This confused me for a good while, because initially I wrote multiple tests for the proc macro with function-local enums deriving Foo:

#[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 ; was at fault.

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 fn).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-macros Area: All kinds of macros (custom derive, macro_rules!, proc macros, ..) A-proc-macros Area: Procedural macros C-bug Category: This is a bug. T-compiler Relevant to the compiler team, which will review and decide on the PR/issue.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants