Don't issue spurious nilary-overrides-nullary warning

[SethTisue]

fixes scala/bug#12851

My ambition had only been to fix the crasher stemming from #10484, but this fixes the underlying spurious-warning bug, too.

@som-snytt I gather from one of your other messages that you've already written a partest for this. So I didn't write one, on the assumption either that your own PR will supersede this PR, or that you'll kindly add your partest to this PR.

What I did do, though, was manually verify that it fixes what I reported in scala/bug#12851, as well as fixing it in the Ammonite repo where the problem originally turned up.

[som-snytt]

The errors are supposed to go thru emitOverrideError so that if the member was inherited, the error is collected in mixinOverrideErrors and emitted at the end of the override checks using the class position instead. TIL.

(I'm sure I saw that in years past without understanding the why.)

I'll see if a PR is forthcoming in a few minutes by tomorrow.

I do see this fix shortcircuits, but if the traits are unrelated, you need to check the override of the composition.

[lrytz]

The errors are supposed to go thru emitOverrideError so that if the member was inherited, the error is collected in mixinOverrideErrors and emitted at the end of the override checks using the class position instead. TIL.

Aha. TWL.

[som-snytt]

is TWL a German thing? Treue Wörter Lauten

[SethTisue]

probably to be superseded by #10512

[som-snytt]

I add the pos test from the other PR, and verified that it fails before.

This fix avoids the case that Seth noted shouldn't even warn: both "legs" of the override pair are compiled separately. The lower leg lacks a source position.

[som-snytt]

The word is not "scurrilous" but "scurrilary".

That's when you have a scurried function.