Parser warnings no longer show in the repl.

When evaluationg a fresh line (scala> def f { println() }), the line (with its wrapping code) is first parsed (In fact it's parsed twice, I'm not sure why) using the existing global.currentRun. The deprecation warning is suspended in PerRunReporting.

The parsed tree is stored in the compilation unit's unit.body.

Then a new run (with a fresh PerRunReporting) is created, so the suspended messages are discarded. The repl then calls run.compileUnits(unit :: Nil). The parser is skipped because unit.body == EmptyTree is false.

Before the change, PerRunReporting had a global flag suppressionsComplete: Boolean, which is set after Typer. This means that the parser warning was reported, because the old run that's used for parsing had the flag set from compiling the previous line. This means that current 2.13.5 doesn't respect @nowarn:

scala> @annotation.nowarn def f { println() }
                                ^
       warning: procedure syntax is deprecated: instead, add `: Unit =` to explicitly declare `f`'s return type

After this patch we have suppressionsComplete: mutable.Set[SourceFile], and the SourceFile for the new line is not in there, so the parser warning doesn't show.

@som-snytt do you know why a new Run is not created immediately when interpreting a fresh line?

In my recent PR to fix the 2.12 backport, I noticed snippet is parsed, reparsed with val res0 =, reparsed to probe for package, then finally full compilation in template. Only the full compile matters for messaging. 2.13 is different and tries to be somewhat tree-oriented. But maybe Run lifecycle is a holdover.

I don't remember how I fixed parser messaging on 2.13. Is this it? #7756 (comment)

Looking at the repl code, I think the fix I implemented here is the best way forward.

The parser is once called through JLine and once through the interpreter, this seems intended.

The complication is that the interpreter potentially calls the parser multiple times (incomplete input), so it would require some logic to avoid creating a new Run each time. On complete input, it calls compile which currently creates a new Run. This would have to be skipped, but not always, there are other entry points into the compile method.

So overall I'd go ahead with the current fix in this PR.