rust/tests/ui/lint/issue-47775-nested-macro-un...

//@ check-pass

#![warn(unused_parens)]

macro_rules! the_worship_the_heart_lifts_above {
    ( @as_expr, $e:expr) => { $e };
    ( @generate_fn, $name:tt) => {
        #[allow(dead_code)] fn the_moth_for_the_star<'a>() -> Option<&'a str> {
            Some(the_worship_the_heart_lifts_above!( @as_expr, $name ))
        }
    };
    ( $name:ident ) => { the_worship_the_heart_lifts_above!( @generate_fn, (stringify!($name))); }
    // ↑ Notably, this does 𝘯𝘰𝘵 warn: we're declining to lint unused parens in
    // function/method arguments inside of nested macros because of situations
    // like those reported in Issue #47775
}

macro_rules! and_the_heavens_reject_not {
    () => {
        #[allow(dead_code)] fn the_night_for_the_morrow() -> Option<isize> { Some((2)) }
    }
}

the_worship_the_heart_lifts_above!(rah);
and_the_heavens_reject_not!();

fn main() {}
-												Use check-pass in ui tests where appropriate

											
										
										
											2019-11-04 08:00:00 +08:00
+								//@ check-pass
-												wherein the parens lint keeps its own counsel re args in nested macros

In #46980 ("in which the unused-parens lint..." (14982db2d6)), the
unused-parens lint was made to check function and method arguments,
which it previously did not (seemingly due to oversight rather than
willful design). However, in #47775 and discussion thereon,
user–developers of Geal/nom and graphql-rust/juniper reported that the
lint was seemingly erroneously triggering on certain complex macros in
those projects. While this doesn't seem like a bug in the lint in the
particular strict sense that the expanded code would, in fact, contain
unncecessary parentheses, it also doesn't seem like the sort of thing
macro authors should have to think about: the spirit of the
unused-parens lint is to prevent needless clutter in code, not to give
macro authors extra heartache in the handling of token trees.

We propose the expediency of declining to lint unused parentheses in
function or method args inside of nested expansions: we believe that
this should eliminate the petty, troublesome lint warnings reported
in the issue, without forgoing the benefits of the lint in simpler
macros.

It seemed like too much duplicated code for the `Call` and `MethodCall`
match arms to duplicate the nested-macro check in addition to each
having their own `for` loop, so this occasioned a slight refactor so
that the function and method cases could share code—hopefully the
overall intent is at least no less clear to the gentle reader.

This is concerning #47775.

											
										
										
											2018-01-31 09:13:05 +08:00
 								#![warn(unused_parens)]
 								macro_rules! the_worship_the_heart_lifts_above {
 								    ( @as_expr, $e:expr) => { $e };
 								    ( @generate_fn, $name:tt) => {
 								        #[allow(dead_code)] fn the_moth_for_the_star<'a>() -> Option<&'a str> {
 								            Some(the_worship_the_heart_lifts_above!( @as_expr, $name ))
 								        }
 								    };
 								    ( $name:ident ) => { the_worship_the_heart_lifts_above!( @generate_fn, (stringify!($name))); }
 								    // ↑ Notably, this does 𝘯𝘰𝘵 warn: we're declining to lint unused parens in
 								    // function/method arguments inside of nested macros because of situations
 								    // like those reported in Issue #47775
 								}
 								macro_rules! and_the_heavens_reject_not {
 								    () => {
 								        #[allow(dead_code)] fn the_night_for_the_morrow() -> Option<isize> { Some((2)) }
 								    }
 								}
 								the_worship_the_heart_lifts_above!(rah);
 								and_the_heavens_reject_not!();
 								fn main() {}