Add rule to use runCatching instead of kotlin.runCatching

[gpeal]

Expected Behavior

Per KTIJ-11561, Android Studio/IntelliJ will autocomplete runCatching to kotlin.runCatching which is inconsistent with other Kotlin APIs such as run which don't do that.

It would be great to have a rule that would enforce that it is used consistently as just runCatching across the codebase.

[BraisGabin]

🤔 This should be work for ForbiddenMethodCall. But I'm not sure if it can handle something like that right now... I'm going to check.

[BraisGabin]

As I was expecting ForbiddenMethodCall can't handle this case right now. For it both functions "are the same".

But the problem is bigger than that. Right now ForbiddenMethodCall doesn't suport:

• functions with lambda parameters (if you want to specify the parameters)
• functions with generics (if you want to specify the parameters)
• extension functions

ForbiddenMethodCall needs to support those three to be able to handle this case. I have a draft for the first case.

[BraisGabin]

🤔 the only way that I can think of handle extension functions with the current "function signature" is to treat the receiver type as the "first paramenter" of the function. This will not create any problem because the compiler doesn't allow you to define this two functions

fun String.hello()
fun hello(world: String)

because they have the same JVM signature. It is the only way I can think without adding a breaking change or deprecate the current function signature and create a new one.

In terms of UX it would be really hacky because it's difficult to think about: fun String.hello() as hello(kotlin.String) but it would work.

[gpeal]

@BraisGabin That's great! I tried adding a separate ForbiddenMethodCall for an extension function yesterday and couldn't figure out why it wasn't working!