Fix used_underscore_binding

[mcarton]

In #944, used_underscore_binding was made allow and to ignore _result as a ugly hack. This should be fixed.

[llogiq]

How? Does a macro check work here?

[Manishearth]

We could just have rustc emit __result instead

[bluss]

using an underscored binding is useful in macros to avoid having the "unused variable" default rustc lint fire for the macro case where it's not needed, while still allowing it to be used for the > 0 argument cases.

[Manishearth]

rustc uses double underscores for "maybe used idk" bindings in macros, clippy doesn't warn on those

[oli-obk]

clippy doesn't warn on used underscore bindings in macros if the binding was declared inside the macro

[oli-obk]

I'm currently evaluating if it's possible to insert the hir-lowerings into the expansion-database, so we can treat them just as we treat macros.

[bluss]

@oli-obk That must be a recent change

[oli-obk]

@oli-obk That must be a recent change

no, you're right, it isn't checked. I wonder why...

[oli-obk]

cc @ThibsG this is the lint we were talking about, but I'm not sure at all whether we do now know that the _result from rustc is unused

[hellow554]

I came across this today, which is a valid reason to use an underscore variable IMHO:

let _unused = get_option();
debug_assert!(_unused.is_some());

[kraktus]

In the above case debug_assert!(get_option().is_some()); would resolve it though

I triggered it with features flag (pseudo-code):

pub fn foo(x: usize) -> usize { internal_foo(x, None) }
#[cfg(feature = "cached")]
pub fn foo_cached(x: usize, cache_key: u64) -> usize { internal_foo(x, Some(cache_key)) } 
fn internal_foo(x: usize, cache_key: Option<u64>) -> usize { ... }

This can probably be avoided if I used internal_foo as a macro rather than a function, but maybe would be worth adding to the output that if intentional could use __variable instead?