Shorten mangled names

[jesyspa]

Our current mangled names are inconveniently long. I'm working on making them shorter, but it's quite a bit of work; this should make things a bit easier to read without reworking too much.

Assigning both of you as reviewers so you can share your thoughts on the readability; there's no behavioural changes here.

[GrigoriiSolnyshkin]

By the way, there is a fun issue that I think we should consider at some point. Kotlin is actually allowed to generate properties with the same name in the same scope although the developer can't do it manually. For example, it desugars x++ to something like val <unary> = x; x = x + 1; <unary>. If there is two increments, two val <unary>s are generated.
Something similar happens when desugaring val (x, y) = ... (a fake property with some fixed name for (x, y) is generated) and when using _ as well.
Maybe it is worth to enumerate all the entities with a given name inside the scope.

[GrigoriiSolnyshkin]

IMO abbreviations seem readable. I would probably stick with lowercase letters between $ because it would be easier to spot them.

In the future I suppose we should document when we use $ and _ as separators and maybe introduce some new ones (as well as some parentheses-like separators which we would use some complex names inside other names, e.g. functions).

[GrigoriiSolnyshkin]

I've come up with the following example:

fun foo(int: Int): Int { ... }
fun Int.foo(): Unit { ... }

It seems to be allowed because JVM signature includes return types.
A simpler sample

fun foo(int: Int): Int { ... }
fun foo(int: Int): Unit { ... }

is rejected on the FIR level.
A case like

fun foo(int: Int): Unit { ... }
fun Int.foo(): Unit { ... }

is prohibited on JVM (but seemingly allowed in FIR). As far as I understand this means that this check happens after our plugin.
Did you mean something else in this TODO?

[jesyspa]

I was actually thinking something like fun foo(a: (Int) -> Unit) vs fun foo(a: () -> Unit, b: Int), but I didn't check.

[GrigoriiSolnyshkin]

I would propose EF for extension functions to avoid some potential problems.

[jesyspa]

We don't currently tag extension functions in any particular way. I'd also personally prefer putting that tag on the type of the parameter, not the function name itself.

[GrigoriiSolnyshkin]

Why do we want this TF if we already have F before in functions? It feels like after introduced abbreviations this T is less readable than take before.

[jesyspa]

Because this is a type, so this makes it consistent with our other types like T_Int. That said, I'm not entirely happy with this either...

[jesyspa]

IMO abbreviations seem readable. I would probably stick with lowercase letters between $ because it would be easier to spot them.

Hmm, that's an interesting one. I feel like the capital letters make it obvious that we're dealing with an abbreviation. But if we make the names more regular, that should be easier to tell anyway.

In the future I suppose we should document when we use $ and _ as separators and maybe introduce some new ones (as well as some parentheses-like separators which we would use some complex names inside other names, e.g. functions).

I agree. I think we use _ when possible because $ looks ugly, but _ can collide because it's allowed in Kotlin names. (On the other hand, so is $ if you escape the name... maybe we should just sanitize it from underscores and stick mostly to underscores?)

[GrigoriiSolnyshkin]

LGTM
I think it's worth to make issues regarding

1. names of function types
2. careful approach to separators
   though

[jesyspa]

Discussed with Francesco: the way we handle predicate names (and class names in general) here is unfortunate. I'll figure out some better way before merging.

[jesyspa]

I have some ideas on how to get things to work better, but they rely on names being a bit less ad-hoc, which is a bigger change. Still, I think it's worth doing. I'll try to get it done this week.

[jesyspa]

I think I fixed the issue discussed with @francescoo22 , but now this is blocked on #230