Formalize the internal IDEA dependencies for binary compatibility

[dkhalanskyjb]

No description provided.

[qwwdfsad]

Friendly reminder

[dkhalanskyjb]

Ah, ok. I misinterpreted the flow of the conversation. After the question about IDEA's side, I thought the review would go, "Well, here's the code where this is used; please go ahead, check it, and update the list of the used method to the actual one since you're at it already."

[qwwdfsad]

Happens :)

We have a full-list here for a different task: https://youtrack.jetbrains.com/issue/KTIJ-24102/Change-coroutine-debugger-implementation-to-use-a-new-package#focus=Comments-27-6989405.0-0

[dkhalanskyjb]

Thanks for the list!
I updated the PR in accordance. Here are the things that I couldn't get to work:

These aren't fields, they have getters.

kotlinx.coroutines.debug.internal.DebugCoroutineInfo
	field context
	field sequenceNumber
	field lastObservedFrame
	field lastObservedThread
kotlinx.coroutines.CancellableContinuationImpl
	field delegate
	field context

I don't know how these names are generated and how to make the compatibility validator know about them:

kotlinx.coroutines.debug.internal.DebugProbesImpl
	method isInstalled$kotlinx_coroutines_debug()
	method isInstalled$kotlinx_coroutines_core()

There are no such fields. Maybe they are hidden somewhere up the inheritance chain.

kotlinx.coroutines.StandaloneCoroutine
	field _state
	field context

I think this is from DispatchedCoroutine. This is an atomic field, so the validator says get_decision$FU. I suppose this is from atomicfu, but I don't understand whether this is expected.

kotlinx.coroutines.CancellableContinuationImpl
	field _decision

Simply doesn't show up in the .api file for some reason:

kotlinx.coroutines.DispatchedContinuation
	field continuation

Not in the library at all:

kotlin.coroutines.CombinedContext
	method get()
kotlin.coroutines.jvm.internal.DebugMetadataKt
	method getStackTraceElement()
	method getSpilledVariableFieldMapping()

Also, pardon my French, but bloody hell!

[qwwdfsad]

Thanks!

These aren't fields, they have getters.

Right, but unfortunately, the underlying private fields are used instead.

I don't know how these names are generated

internal names that are not classes/interfaces are mangled, so it's impossible to call them from Java ($ is not a valid identifier in Java). The default mangling strategy for internal modifier is name + $ + module name

how to make the compatibility validator know about them

No way, neither there should be, because they are internal.

Maybe they are hidden somewhere up the inheritance chain.

One is JobSupport._state, the other one is the underlying field for the getter. Hint: CTRL+F12 pressed twice enables "Inherited members" overview in IDEA.

Simply doesn't show up in the .api file for some reason:

Explicitly excluded here: https://github.com/Kotlin/kotlinx.coroutines/blob/master/build.gradle#L136

Also, pardon my French, but bloody hell!

This all is a very educational story about project management and responsibilities in general, but this margin is too narrow to contain it :)

[qwwdfsad]

LGTM, good job figuring it out and consolidating;

Feel free to merge, not doing so myself in case you have any questions/additions