any compiler source I could peek at for what kotli...

# kotlin-toolchain

[Zac Sweers]

any compiler source I could peek at for what kotlin toolchain uses for these? Reason I ask is because Metro's upcoming release (second screenshot, sans markup) has very similar diagnostics and I'd like to try to align it to match kotlin's if it's going this direction :)

[Zac Sweers]

think it's this! https://github.com/JetBrains/kotlin-toolchain/blob/faa90f90543654dbcac02ad157b22ef7bef33517/sources/amper-cli/src/org/jetbrains/amper/compilation/TerminalCompilerMessageRenderer.kt#L7

[Zac Sweers]

One thing I wonder about with this though, if a compiler plugin does its own rich output, is there a concern about basically the toolchain then adding unhelpful noise?

[joffrey]

You got it right Zac. I have zero experience with compiler plugins, but can't you report diagnostics the same way as the compiler? Like can't you generate the same structured diagnostic objects that the toolchain would then get from the compiler?

[joffrey]

How are you getting this output right now? Are you printing directly the output?

[Zac Sweers]

so we do, but currently the gradle setup doesn't show source snippets with the sort of rust-style like this, it purely prints the message + the location

[Zac Sweers]

it looks like this is doing some extra stuff to print the source range + the underlining carets to point it out?

[Zac Sweers]

so I'm imaging that metro reports this line, prints its rich diagnostic, then kotlin-toolchain prints a secondary duplicate of it because that's what the reported source location is

[joffrey]

it looks like this is doing some extra stuff to print the source range + the underlining carets to point it out?

Indeed, on the Kotlin Toolchain side, we process structured compiler diagnostics provided by the Build Tools API, and format them manually in this pretty rust-like format via the class you have already found.

In Gradle, I'm not sure who's responsible for printing. Maybe the Kotlin Gradle Plugin prints the diagnostics in this more simple form, or maybe it forwards compiler diagnostics to Gradle in a Gradle-specific structured diagnostic format, and Gradle prints it. Either way, I guess it's out of your hands as a compiler plugin author, which is why I was wondering whether you print the message yourself from the compiler plugin, or you forward this pretty message inside a compiler diagnostic.

[joffrey]

One way to approach this could be to format your messages differently depending on whether your plugin runs in Gradle or the Kotlin Toolchain. Not very nice, but it would do the job. I know @Oliver.O for instance did something like this to condition some workarounds he did in TestBalloon so they are only run when using Gradle

[joffrey]

I'd say the other way is to accept that it's not your responsibility to format the messages, but only to provide the proper source location and let the caller format as needed. Then maybe open an issue on the KGP side to get nicer formatting in Gradle.

[joffrey]

(Of course, we can do both: do it yourself conditionally in the meantime, but still ask whether KGP could do something about it)

[Zac Sweers]

who's the "caller" in that example? In my case I am reporting a location but my plugin has more context to show relevant details than the build tool does on its own

[Zac Sweers]

also sidebar: how are you handling IDE vs CLI? The former won't render mordant rich outputs well, unless mordant is IDE-aware automatically. I'm currently checking an internal (as in, not participating in compilation task inputs) option that's backed by a system prop detection

[joffrey]

By "caller" I mean the caller of the compiler. So the Kotlin Toolchain, or Gradle, or maybe even the IDE for analysis.

My point is solely about the formatting of the snippet of code and the highlight of the location in the snippet. If your plugin has more info than that to add to the diagnostic, it's totally fine to add to the message. But IMO you're not supposed to add redundant location info inside the message.

[joffrey]

Regarding IDE vs CLI, we don't do anything special. The IDE handles compiler diagnostics itself during analysis I believe, and it uses the location to highlight stuff directly in the editor. That is, unless you're talking about when some IDE actions call the Kotlin CLI. In that case, Mordant is aware of the capabilities of the different terminals, so it detects whatever the IJ terminal or tool windows are capable of, and adjusts the output accordingly.

[Zac Sweers]

yeah I mean specifically when you run a build in the IDE and maybe have a diagnostic reported from IR, not the FIR that runs in the editor

[Zac Sweers]

in my initial experience testing with rich output, this was a no go because mordant didn't know it wasn't a terminal and all the markup glyphs got mangled in the final error output that the IDE's build window would show