A modern programming language that makes developers happier.

kotlinlang

I'm currently looking at <https://youtrack.jetbrains.com/issue/KT-39891|KT-39891> . As mentioned in the ticket the problem could be solved by adding `toString()` calls for the different `expression.arguments` (<https://github.com/JetBrains/kotlin/blob/7c62e9aecdc59d23be94cb8946daf10094fb8f7d/compiler/ir/backend.js/src/org/jetbrains/kotlin/ir/backend/js/transformers/irToJs/IrElementToJsExpressionTransformer.kt#L74-L80|here>). The "pre IR" translator had a <https://github.com/JetBrains/kotlin/blob/f3a935adb98008a0af08d4a8a48c0cea834067e9/js/js.translator/src/org/jetbrains/kotlin/js/translate/expression/StringTemplateTranslator.java#L113-L130|similar mechanism>. However I'm unsure why the pre IR code also added `toString` for the other types (Any, Comparable, Number)? At least if I look at the kotlin.js , I can only see `Long` and `BoxedChar` implementing `valueOf` .

Ok, I think I just understood why it also needs to add `toString()` for types `Any` ,`Number` and `Comparable` . These are the interfaces/super classes that are implemented by Long :man-facepalming:

Does it make sense to add the `toString()` calls directly in the `IrElementToJsExpressionTransformer` or would it be better to handle such cases during the "lowering" ? Adding the `toString` calls for "normal" values would be easy, however it gets more complex if the values are optional

I think it’s better to do by lowering, otherwise, for example, we need keep in sync it with DCE.

I gave this a shot on the weekend and implemented some lowering steps that would fix this issue: <https://github.com/JetBrains/kotlin/pull/4364>

<@U0BMF6PDJ> is this going in the direction you had in mind?

<@U6VGSR605> Hi! I’m sorry for the delay. We will take a look on it soon.

Thanks :+1: . I'll try to rebase the PR as well. But I think I will only get to it starting next week