No warning for parameter of overriding method

[som-snytt]

Quiet the unused parameter warning when the method is an override.

Fixes #22742

[Gedochao]

@som-snytt what's the reasoning behind the option being -Y instead of -W or -X?
If we consider this a fix for #22742, I wonder if we shouldn't have something with proper guarantees (which -Y private flags don't have).

I'd rather have smth like -Wunused-heuristics down the road. We could also leave the ticket open and stabilise this until 3.8, at which time we'd rename it to -W/-X?

[som-snytt]

@Gedochao I think a "fix" or workaround (for the expectation that it doesn't warn when overriding) is useful for 3.7. (I like that this is a small delta in LOC.)

Experience suggests that a "false positive" or noise makes a warning unusable.

OTOH, altering settings (names or behaviors) makes cross-compilation harder. Maybe that is less of a concern in LTS world?

Currently, we're stuck with -Wunused:strict-no-implicit-warn,unsafe-warn-patvars because it's hard to take away an option; the words are baked in stone.

If a -Y is deemed terrible by the team, the alternative is not to offer an option (at least not yet), but default to "fewest warnings".

I didn't do that because I wanted to make progress on "strict" mode; this is a gray area because offering too many "knobs" is counterproductive: it's awkward to configure the build, and only the typelevel plugin handles the "matrix" of options.

I just talked myself into "default to fewest warnings." Am I permitted to offer -Y for those mavericks who want more warnings?

[som-snytt]

Edit: I will push without -Y so that we don't need to have that conversation. This fix will just restore "don't warn when overriding".

[som-snytt]

Of course I must update other check files, because the "no warning" is unconditional now.

[som-snytt]

Example where I would say this rule is suboptimal.

override def equals(other: Any) = toString.nonEmpty

• "But I don't control the signature!"
• "What if I want to ignore the parameter!"

I think it must be written def equals(@unused other: Any). That is not burdensome, and is shorter than a code comment. I don't have to wonder if it's a typo.

The "trivial RHS" check tries to cover "obvious that parameters are not used", such that it's not likely to be human error. However, if start coding with a "default" RHS (that does not warn), what if I "forget" to improve it. (Presumably, a test is also lacking.)

"Dev" mode could be lax, "Integration/C.I." mode could be strict.

Similarly def equals(other: Any) = true // subclasses must override. Maybe in Scala 3 you can make it abstract (deferred)? for that use case.