Following up from this discussion - <https://githu...

# compiler

[Zac Sweers]

Following up from this discussion - https://github.com/JetBrains/kotlin-compiler-devkit/issues/65#issuecomment-2959026792

I'm trying to look at using DiagnosticReporter instead of MessageCollector to report errors from my IR transformers, but all the reporting functions I see appear to only speak FIR symbols. Is there an example of using this in IR I could look at for inspiration?

[Zac Sweers]

I don't see any relevant key for it in CommonConfigurationKeys and the closest example I can find is DiagnosticReporterFactory.createReporter(messageCollector) in compose-compiler, which just wraps a MessageCollector

[Zac Sweers]

Happy to file a FR to youtrack instead if this is not possible in IR and the real request is just asking the test framework to support reading IR diagnostics

[dmitriy.novozhilov]

There is a IrPluginContext.diagnosticReporter, I meant it in the issue thread.

Here you can see how it's used from the compiler

[Zac Sweers]

What compiler version is `FirDiagnosticsContainer`/`KtDiagnosticsContainer` introduced in? Doesn't look like it's available in 2.2.0-RC2

[dmitriy.novozhilov]

2.2.20-beta1 IIRC

[Zac Sweers]

Ok I've gotten farther and am seeing it report correctly, but I'm still not seeing the actual diagnostics captured in the dump. This might be a silly question but what would the right base class be to use for this case? Currently I'm using open class AbstractIrDiagnosticTest : AbstractPhasedJvmDiagnosticLightTreeTest() but that seems to be more for frontend diagnostics

[Zac Sweers]

where I'm at currently for reference: https://github.com/ZacSweers/metro/pull/447

[dmitriy.novozhilov]

I'll take a look tomorrow

[dmitriy.novozhilov]

What I found:
1. RENDER_DIAGNOSTICS_FULL_TEXT works for diagnostics reported frontend or backend, but plugins are executed at fir2ir stage, so they are skipped by the corresponding handler.
2. There is a trick which allows to render diagnostic arguments right inside the .kt file. For that you need to add ("") to the diagnostic tag and rerun the test: <!GRAPH_DEPENDENCY_CYCLE!> -> <!GRAPH_DEPENDENCY_CYCLE("")!>. But in your case it won't work also, as you have ReversibleSourceFilePreprocessor registered (MetroDefaultImportPreprocessor), which messes up offsets for meta-infos (test infra parses them not knowing about preprocessors, but plugin reports diagnostics against modified file)
So what can you do:
1. Introduce new fir2ir handler, similar to JvmBackendDiagnosticsHandler which will report diagnostics from fir2ir into .diag file and use it (can be also contributed to kotlin.git)
2. Disable sources preprocessor for specific tests where you care about diagnostic message and use the trick with ("")
3. Teach GlobalMetadataInfoHandler to work with `ReversibleSourceFilePreprocessor`s and contribute it to kotlin.git

[dmitriy.novozhilov]

For reference, here is how diagnostic looks like after I disabled the preprocessor and rerun test:

...
interface <!GRAPH_DEPENDENCY_CYCLE("Graph dependency cycle detected!    test.StringGraph is requested at        [test.CharSequenceGraph] test.StringGraph.Factory#create()    test.CharSequenceGraph is requested at        [test.CharSequenceGraph] test.CharSequenceGraph.Factory#create()")!>CharSequenceGraph<!> {
...

[dmitriy.novozhilov]

Actually, I found that there is also a RENDER_IR_DIAGNOSTICS_FULL_TEXT, which does exactly what you need.

[Zac Sweers]

ahh perfect. I had seen that but assumed it was implicitly enabled by RENDER_DIAGNOSTICS_FULL_TEXT

[dmitriy.novozhilov]

I'll probably merge all of these directives in one, but only when 2.2.20 branch out and master will switch to 2.3.0 state.
Currently some of these directive tracks also K1/K2 dumps in different files, which makes merging not trivial.
But with 2.3.0 we (finally) can drop most of K1 tests