Also having the SUPPRESSION_LABEL in the compiler ...

# compiler

[Darryl Miles]

Also having the SUPPRESSION_LABEL in the compiler output helps with CI statistics for a large code base, as a team might apply a points system to different kinds of messages based on risk, so it allow easy collation and reporting of quality over time

[Youssef Shoaib [MOD]]

https://kotlinlang.slack.com/archives/C0B9K7EP2/p1678800537548289?thread_ts=1678799268.012699&cid=C0B9K7EP2

[Youssef Shoaib [MOD]]

https://kotlinlang.slack.com/archives/C0B9K7EP2/p1678801108283329?thread_ts=1678799268.012699&cid=C0B9K7EP2

[Darryl Miles]

Thanks for the links.

Not sure on the "internal mode" approach, it appears to be requesting I restart IntelliJ in some special mode, to be able to get at what I think should be a regular/supported/standard feature (content assist for all valid @Suppress labels as a minimum, with offer suggestion as a nice to have)

With the -Xrender-internal-diagnostics-names this is exectly what I prefer, however the name "internal" in there is a misonomer, because they are external contract API labels the moment the customer needs them in their @Suppress in their project. Also I don't need them to be on ERROR messages too, only for scenarios that have a suppression, however having them for both is better than not at all.

Thanks again for reply.

[Youssef Shoaib [MOD]]

I think they're internal in the sense that they're used to identify them internally within the compiler, and a lot of these errors aren't "meant" to be suppressed, and suppressing then can result in unexpected behaviour.
The internal mode approach is safe. I have it on in Idea all the time. It just activates a special flag to tell it to display those error names. As you might appreciate, those error names weren't intended to be user visible when they were written. The error messages are the part intended to be visible.

[Darryl Miles]

Maybe my expectations are too high, I am wanting 1st class support for @Suppress("UNUSED_PARAMETER") the kotlin codebase is littered with them itself. Or just bring back the original @SuppressWarning("") from Java

[Youssef Shoaib [MOD]]

That's fair yes. I think suggesting suppressions for warnings that are expected to be suppressed is reasonable.

[dmitriy.novozhilov]

IDEA actually offers suppress any warning in the code

[dmitriy.novozhilov]

however the name "internal" in there is a misonomer, because they are external contract API labels the moment the customer needs them in their @Suppress in their project

Description of Youssef is quite correct
The only thing I'd like to add that those names are not meant to be stable. If some diagnostic name will be changed it doesn't break non binary or source compatibility. It just may bring the new warnings to be reported
It indeed may break the compilation with -Werror, but in the same way as any other actually new warning added to the compiler

[Darryl Miles]

Only noticed this reply today, thanks for the update. I think @Suppress("UNUSED_PARAMETER") is a common case and will always be external API contract, but still IDEA does not offer to as an action to solve, or content assist around it. Understand that many of the OTHER suppression types are still considered internal API, but that is not my use case.
Many signature of callback can not have their parameters changed, or maybe it is legacy API that can not have signature changed to remove the param.