Giving a trait method a default implementation can trigger unused_variables warnings

[chris-morgan]

trait X {
    fn foo(bar: Bar);
}

Fine, no warnings.

But give it a default implementation that doesn’t use all those arguments (a perfectly plausible and reasonable situation):

trait X {
    fn foo(bar: Bar) { }
}

A warning:

<anon>:2:12: 2:15 warning: unused variable: `bar`, #[warn(unused_variables)] on by default
<anon>:2     fn foo(bar: Bar) { }
                    ^~~

Arguments to a trait fn default implementation should be considered immune from unused variables warnings, because their names are a part of the API as it gets documented.

The alternatives are (a) prefixing the variable name with an underscore, which is ugly in generated API docs; and (b) tacking #[allow(unused_variables)] onto the fn foo, which then silences other legitimate unused variables warnings in the body of the function.

[apasel422]

This is a duplicate of #26487.

[SoniEx2]

Why not split unused_variables and unused_parameters?

[SoniEx2]

Or why not just use

trait X {
    fn foo(bar: Bar) {
        let _ = bar; // a la `(void)x;` in C?
    }
}

[chris-morgan]

Not certain how I missed the existing issues when searching for it. I suspect I accidentally had it filtered to only open issues. Ah well. I still think it should be done, but this issue is not necessary.

[SoniEx2]

I feel like the "a la (void)x;" solution is the cleanest. Increasing compiler complexity for the unused_variables lint isn't needed.