After updating ksp to 1.6.20-1.0.5, Moshi generates error code for typealias of class with type parameters

[efemoney]

This may as well be a bug in ksp but after updating kotlin & ksp to 1.6.20-1.0.5, given:

typealias EventMetadata = Map<String, String>

@JsonClass(generateAdapter = true) 
data class ClassUnderTest(
  val metadata: EventMetadata,
)

in the generated code, the Map loses its type arguments and is therefore a compile error.

[yigit]

This might be related to: google/ksp#881

[ting-yuan]

The above change was introduced in KSP 1.0.5, where type arguments are now returned for the reference, instead of the complete, underlying type. In this case, it is a reference to an alias and therefore the arguments defined in declaration of the alias are not included.

KotlinPoet relies on the original behavior. This test caught the issue when I tried to bump KSP to 1.0.5.

[Egorand]

Hey @ting-yuan, I'm trying to upgrade KotlinPoet to 1.6.20-1.0.5 and bumped into this issue. Any suggestions on how to migrate the logic? Here's what I've got at this point:

For the following declaration:

genericMapAlias: GenericMapTypeAlias<String, Int>,

where

typealias GenericMapTypeAlias<V, K> = Map<K, V>

I can access:

• KSTypeReference.element.typeArguments = [String, Int]
• KSTypeAlias.typeParameters = [V, K]
• KSTypeAlias.type.declaration.typeParameters = [K, V]

I can match parameter names manually and put the type arguments in the right order, but wondering if there's a simpler way to do this.

[ting-yuan]

I think what you mentioned (match parameter names and put type arguments in the right order, which is how KotlinPoet worked with KSP 1.0.4, right?) is probably the simplest/best way.

Thanks for fixing this. My apology for not noticing and announcing the behavior change in KSP.

[Egorand]

which is how KotlinPoet worked with KSP 1.0.4, right?

KotlinPoet was behind by a couple major versions, so we're migrating only now.

Here's the commit, would appreciate a review! square/kotlinpoet@abbcc17

[ting-yuan]

@Egorand I left 2 comments for corner cases. Otherwise LGTM.

[ZacSweers]

@Egorand has fixed this upstream in KP, will keep this open until we update here

[adauvalter]

I figure the same situation after update kotlin to 1.70 and ksp to 1.0.6 with List which returns One type argument expected for interface List<out E>. Any plans to roll out a new release?

[yogurtearl]

I think this was fixed by #1543

[ZacSweers]

Sorry for the delay, we are in the middle of a significant 2.0 migration so it's not easy to squeak out a simple next release at the moment

[mannodermaus]

Shading of the transitive dependency might make this tough, but is there a way to update Kotlinpoet while sticking with Moshi 1.13 and get around this problem? A first trivial attempt didn't work:

dependencies {
  implementation("com.squareup.moshi:moshi:1.13.0")
  ksp("com.squareup.moshi:moshi-kotlin-codegen:1.13.0")

  // nope
  ksp("com.squareup:kotlinpoet:1.12.0")
  ksp("com.squareup:kotlinpoet-metadata:1.12.0")
  ksp("com.squareup:kotlinpoet-ksp:1.12.0")
}

[ZacSweers]

The KSP APIs in Kotlinpoet are now stable in its latest release, so what I'm thinking is we cut a patch release where the sole change is removing the shading. This way folks aren't prevented from forcing a newer version. I'll talk with folks about options