Implement Resolver.getModuleName API

[ZacSweers]

Resolves #1621

[ting-yuan]

Could you run ./gradlew updateApi to update the api.base?

[ting-yuan]

BTW, although this is a simple API, it'd be nice to have tests. For example, you may copy this and add a check after adding a logger.warn(moduleName) in the processor.

[ZacSweers]

I added a test but was surprised to find that K1 and K2 have different behavior here 😰. The APIs appear to be the same in docs, but K1 uses the project module name and K2 appears to use the source set name. Lmk what you want to do, or if you're fine with the current difference and can explore more later

[ZacSweers]

Weirder still, this test worked for me locally at first, and now... doesn't appear to run the processor at all? 🫠

[neetopia]

I added a test but was surprised to find that K1 and K2 have different behavior here 😰. The APIs appear to be the same in docs, but K1 uses the project module name and K2 appears to use the source set name. Lmk what you want to do, or if you're fine with the current difference and can explore more later

Inconsistent behavior is expected between K1 and K2, it is better to confirm with JB on this inconsistency to see if that's the expected behavior from their side, we are OK with inconsistent behavior if it is expected.

[ting-yuan]

According to the comment, should this be in the reversed order?

[ZacSweers]

Yes!

[ZacSweers]

3b572cc

[ting-yuan]

Is the difference also observed in the mangled jvm names in K1 and K2? If so, for the purpose of the issue referenced, they have to be different in KSP too. Otherwise, either the KSP1 or KSP2 changes need to be adjusted.

By the way, don't Resolver.getJvmName or Resolver.mapToJvmSignature work for you?

[ZacSweers]

Apologies, I completely forgot about this. Asking for clarification on the K2 behavior change in kotlin-lang slack here: https://kotlinlang.slack.com/archives/C03PK0PE257/p1709960362349149

By the way, don't Resolver.getJvmName or Resolver.mapToJvmSignature work for you?

Could you elaborate on this? I wasn't sure what you're referring to but maybe it's because I just haven't looked at this in a minute

[ZacSweers]

I'm fairly convinced at this point that KtSourceModule.stableModuleName/KtSourceModule.moduleName are just plain broken in K2, and escalating this issue: https://youtrack.jetbrains.com/issue/KT-66713

[ZacSweers]

@ting-yuan after feedback on the above issue, I think I've resolved this 🥳

[ting-yuan]

Apologies, I completely forgot about this. Asking for clarification on the K2 behavior change in kotlin-lang slack here: https://kotlinlang.slack.com/archives/C03PK0PE257/p1709960362349149

By the way, don't Resolver.getJvmName or Resolver.mapToJvmSignature work for you?

Could you elaborate on this? I wasn't sure what you're referring to but maybe it's because I just haven't looked at this in a minute

I mean, should Resolver.getJvmName or Resolver.mapToJvmSignature just fit your use case? Given a KSDeclaration, they should return the mangled names in JVM.

[ZacSweers]

It's possible, but there are so many added permutations for handling custom getters, is prefixes, and handling value classes that it's easier/more flexible to just have access to the module name directly

[ZacSweers]

@ting-yuan @neetopia anything else you need from me for this?

[ting-yuan]

LGTM, thanks for the patch! Would you mind to rebase it to ToT so that it can be cherry-picked into release branches by CI?

[ZacSweers]

Rebase or is merging latest main ok?

[ZacSweers]

@ting-yuan done but let me know if you'd prefer a full rebase. I try to avoid it after having done main merges due to code review and also git's propensity for uh, not handling mixing them well 😅

[ting-yuan]

I'd really appreciate a full rebase. Our auto-cherry-picker doesn't work with merge very well 😢 Don't worry about the review. I'll go through it quickly again before merging.

[ZacSweers]

I'm just going to open a fresh PR with the changes then

[ZacSweers]

#1847