Fix messages leaking via suspended messages

[dwijnand]

It isn't clear what StoreReporter's purpose is. Is it simply a store of
all messages, or is it a store of "real" messages, i.e. messages that
aren't suppressed with @nowarn or -Wconf (i.e. configurable warnings)?
I believe StoreReporter is often used as a way to get programmatic
access to the real messages.

Typer, with its TyperState, uses StoreReporter as a more general buffer
while making typing attempts, such as when trying to apply an implicit
conversion. But with configurable warnings, we don't know if a warning
is real or not until we've typed all the @nowarn annotation in the
code, which is why we suspend the messages, on Run.

So we add an override for TyperState, so that StoreReporter is used as
simply a buffer. When it then unbuffers its messages in flush to the
parent context's reporter, it will run through the regular
"issueIfNotSuppressed" code (assuming it's not another store reporter).

[test_java8]

[lrytz]

For reference, in Scala 2, reports during type checking go through an additional layer (ContextReporter, separate class hierarchy from Reporter). Silent type mode for inference uses the BufferingReporter subclass of ContextReporter. This happens before any of the WConf/nowarn infrastructure looks at messages.

Scala 2 also has a StoreReporter, which is used for when messages should be made available as data instead of going to the console.

Scala 3's StoreReporter is used for both of these use cases. The bug is that the WConf infra can itself buffer messages (into the Run). This is needed because @nowarn suppression ranges are only known after typer. In silent mode / inference, messages buffered in the Run don't make it to the StoreReporter's buffer, so they are not discarded when an implicit alternative is discarded.

I guess an alternative fix would be to make removeBufferedMessages also handle messages buffered in the Run during the lifetime of that StoreReporter.

[lrytz]

It seems that there's a slight change; ctx.settings.silentWarnings.value used to be checked before WConf, now it's after. So before, silentWarnings would silence any warning, now it only silences warnings that WConf doesn't turn into errors.

To me the change is fine, it's probably the better way to do it.

[dwijnand]

Yeah... I can't remember why I made that change. I don't really know what the use cases are for -nowarn.