WIP message suppression mechanism

[martijnhoekstra]

Message suppression/escalation mechanism

Implements suppression as a compiler flag by messageID number.

Implements two existing message manipulation flags (fatal warnings, silent warnings) on top of the general suppression mechanism.

Looking for feedback on the general strategy.

[dottybot]

Hello, and thank you for opening this PR! 🎉

All contributors have signed the CLA, thank you! ❤️

Have an awesome day! ☀️

[SethTisue]

@martijnhoekstra intriguing! supposing we can settle on a design, might you be interested in working on a Scala 2 backport as well?

[adriaanm]

I have a baby step towards configuring deprecation warnings for scala 2.13: scala/scala@2.13.x...adriaanm:deprconf

[smarter]

Here's an idea: move ErrorMessageID.java to dotty-library, so that user code can do something like @SuppressWarnings(PureExpressionInStatementPositionID, UncheckedTypePatternID) def foo = ...

[martijnhoekstra]

I would be entirely willing to work on porting this to scala2, but that probably would involve porting much the reporting infrastructure of dotty to scala2. That would be nice to have for multiple reasons, but I'm not clear on how feasible that is.

I haven't had the chance to properly understand Adriaans sketch yet.

The reason I have gone with just a compiler flag for now is that I wanted to be able to have simple access to what you want to suppress at all times. This is because warnings that you want to suppress could be parse warnings, and I'd imagine it would be difficult to get annotation values (or even scopes) at the moment you want to emit a parser warning. The only ways I see around that is either delay reporting to at least after parsing, or do a two-pass parse with some new pragma syntax on the first pass to enable and disable suppressions in blocks of code separate from the scala part.

The first has a lot of ifs and buts (conceptually emitting warnings only when you either leave a phase that ensures you can read the annotation or, you have a separate compile error and won't be able to read the annotation at all is relatively clear, but I wouldn't know where to start, and sounds like something that could get hairy), and I don't think I would be able to implement that (which is mostly a statement about me, not nessecarily about whether it could be done)

The second is really ugly IMO, and not worth it.

That said, that doesn't mean it wouldn't be really nice to be able to suppress with annotations for warnings emitted at a point you can reliably get to the value in the annotation, but on top of, rather than instead of (something like) this.

[martijnhoekstra]

Just as a note, I have a bunch of stuff on my OSS plate right now that I'm not really coming to, and this is one of those things, in addition to being really busy with work, and falling behind on OSS stuff in general. I'll have some time in the first week of the new year, but don't expect this PR to mature further before then.

…

On Mon, Dec 10, 2018 at 4:48 PM Allan Renucci ***@***.***> wrote: Assigned #5337 <#5337> to @martijnhoekstra <https://github.com/martijnhoekstra>. — You are receiving this because you were assigned. Reply to this email directly, view it on GitHub <#5337 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AA13EbTjw1O1BlYCkIwQlxtikt7o687Rks5u3oJPgaJpZM4YBf-q> .

[OlivierBlanvillain]

@martijnhoekstra Do you still plan to spend time working on this PR?

[martijnhoekstra]

@OlivierBlanvillain yes, but that planning keeps on slipping -- I hoped to have time around Christmas/new years, but that didn't pan out. So I'm closing for now, and re-open if I do find the time to bring such a proposal to a mergeable state.

[SethTisue]

see also scala/scala#7790, scala/scala#7728, scala/scala#7714