I'm trying to suppress a warning that is elevated ...

# compiler

[eygraber]

I'm trying to suppress a warning that is elevated to an error by using the new management of compiler warnings for the following warning:

w: Language version 1.9 is deprecated and its support will be removed in a future version of Kotlin

e: warnings found and -Werror specified

however there is no indication of what the DIAGNOSTIC_NAME is.

[phldavies]

try adding -Xrender-internal-diagnostic-names as a freeCompilerArg

[eygraber]

That didn't work

[dmitriy.novozhilov]

That one is not suppressible right now, because technically it's not a diagnostic, but plain string with warning severity.
I'm working on transforming all of such warnings and errors to be real diagnostics right now, so it would be available in 2.2.20 or 2.3.0

[dmitriy.novozhilov]

https://youtrack.jetbrains.com/issue/KT-78277/Dont-use-MessageCollector-for-reporting-diagnostics-across-the-compiler

[Olaf Gottschalk]

I had the VERY same question. How do I get to the concrete DIAGNOSTIC_NAME of any given warning... Why is this not documented? I mean, JetBrains is so good in documentation, I am stunned this is missing. I cannot use this new feature unless I know all of these keys!

I need to switch off this warning:

w: Experimental context receivers are superseded by context parameters.
Replace the '-Xcontext-receivers' compiler argument with '-Xcontext-parameters' and migrate to the new syntax.

See the context parameters proposal for more details: <https://kotl.in/context-parameters>
This warning will become an error in future releases.

Also tried free compiler arg: -Xrender-internal-diagnostic-names - also did not see any diagnostic name... 😞 (and if this works for some, why is this not documented right next to the new feature of changing the levels?)

Could it be that most of the stuff people need to suppress aren't actually diagnostics at all? 😞

[dmitriy.novozhilov]

This one is not suppressable too, sorry.
That's one of the reasons why this feature with global suppress in the experimental state right now

[Olaf Gottschalk]

Shoot.... this is really really... sad. 😄 I know you mean well with these messages, but this is overkill. Knowledgeable programmers KNOW that they need to move from receivers to parameters and we have waited for this to come for quite some time. But the problem now is that it always looks like something is broken to others. Plus: I do scripting and error / warning parsing, so I need to manually filter out these messages in the ResultWithDiagnostics result member by matching the exact string...