Add CustomKotlinLikeDumpStrategy.nameOf API

[ZacSweers]

Currently, class names in dumpKotlinLike() always just print the simple class name. This works fine in a lot of scenarios, but is ambiguous in scenarios where the class name is either a companion object or a common/generated simple name. This is a proposal API to allow customization of class names with added container context.

If this is acceptable, I can also add a test to the sandbox.

Open questions (aside from the API itself)

1. Should this expand to any named declaration?
2. Should we tweak the existing behavior to, for companion objects, print the parent class + companion for clarity? I am not sure there are many scenarios where just Companion is desirable. Though it would be a large change to existing dump files.

Here is an example PR using a fork based on this API: ZacSweers/metro#1976

[kotlin-safe-merge]

Code Owners

Rule	Owners	Approval
/​compiler/​ir/​ir.​tree/​	kotlin-common-backend	🔴

[ddolovov]

Hi. Could you please provide examples when printing companios object's simple name is not sufficient?

From my experience, it's usually the top-level class that is dumped. So, there would be a nested object that would be structurally visibly as located under the class. Something like this

class Foo
  companion object Companion {
    ...
  }

Isn't that clear enough?

[ZacSweers]

There are a lot of examples in the linked PR. It's not about class dumps but rather how IrCall expressions are rendered, as they do not currently show any context indicating what class's companion object is being invoked.

[ddolovov]

There are a lot of examples in the linked PR. It's not about class dumps but rather how IrCall expressions are rendered, as they do not currently show any context indicating what class's companion object is being invoked.

OK, I see. It's about replacing

Companion.newInstance(b = <this>.#b.invoke(), e = <this>.#e.invoke())

by something like

MetroFactory/* companion */.newInstance(b = <this>.#b.invoke(), e = <this>.#e.invoke())

I'd say it's better to render the exact name of the companion object instead of adding /* companion */ comment, because companions may have different names. Ex:

class Foo {
    companion object Bar
}

But it's up to you, because the actual nameOf() implementation is in your repository.

[ddolovov]

Could you please squash commits into a single one?

[ddolovov]

I am not sure container parameter is necessary. We can always deduce the container from the declaration using IrDeclaration.parent.

[ZacSweers]

the declaration being referenced here isn't necessarily in the container though. This is like a context scope, whereas the declaration is the resolved referenced class

[ddolovov]

I think it would be useful to have a more generic version of nameOf() suitable for any IrDeclarationWithName.

[ZacSweers]

Done!