Support direct annotation instantiation in code gen on Kotlin 1.6

[ZacSweers]

Resolves #1382. This also implements it gated on the target type's language version, which allows this to seamlessly work in a backward-compatible way.

Generated adapter now looks like this

public class GeneratedAdaptersTest_PropertyWithQualifierJsonAdapter(
  moshi: Moshi
) : JsonAdapter<GeneratedAdaptersTest.PropertyWithQualifier>() {
  private val options: JsonReader.Options = JsonReader.Options.of("a", "b")

  private val stringAtUppercaseAdapter: JsonAdapter<String> = moshi.adapter(String::class.java,
      setOf(GeneratedAdaptersTest.Uppercase(inFrench = true)), "a")

  private val stringAdapter: JsonAdapter<String> = moshi.adapter(String::class.java, emptySet(),
      "b")
      
  // ...
}

[ZacSweers]

The failure is interesting. Basically, the AdapterMethodsFactory quality check here fails, but I'm not sure if this is a bug on our end or Kotlin's. Trying to reproduce it in a simple case

moshi/moshi/src/main/java/com/squareup/moshi/AdapterMethodsFactory.java

Line 318 in a1852a7

if (Types.equals(adapterMethod.type, type) && adapterMethod.annotations.equals(annotations)) {

[ZacSweers]

It's a bug on their side with hashCode(), filed here https://youtrack.jetbrains.com/issue/KT-48606

[ZacSweers]

Looks like it's not in the 1.6-M1 branch yet. Will try again when it is

[ZacSweers]

Still broken in 1.6.0-M1, pushed to 1.6.0-RC now -_-

[ZacSweers]

Small update after talking with @swankjesse

• We'll add an option to optionally disable this behavior, in case there's lingering bugs with the Kotlin implementation
• It will be enabled by default for Kotlin 1.6+

Will wait for #1393 to merge in and Kotlin 1.6-RC (which should have this implemented)

[ZacSweers]

[ZacSweers]

Got an interesting problem here.

In short, we reuse AnnotationSpec instances for qualifiers. Since we’re directly instantiating them now, we can just reuse them and join their members as the constructor args. However, internally in kotlinpoet it uses collection literal [...] syntax for arrays, but that isn’t allowed in regular construction.

So there’s three options I can think of:
A. We change AnnotationSpec.get() to not use collection literal syntax. Use arrayOf() to maximize portability/reusability
B. We add a parameter/configuration option somewhere to control this. Would probably be hard to write in and we’d need to introduce something like a CodeWriter with configurable behavior like Moshi’s JsonWriter
C. We try to manually patch the underlying CodeBlock for array types from an AnnotationSpec. This seems really error prone

I think we should go with option A. Doesn’t read as nicely but it’s definitely in the spirit of portability like other changes have been (explicit public modifiers, imports from kotlin.*, etc). lmk what you think

[efemoney]

lmk what you think

I agree, AnnotationSpec should be updated to arrayOf

[Egorand]

Delete if not needed?

[ZacSweers]

Good catch, will remove before merging

[ZacSweers]

actually going to leave it but with a comment explaining it's just temporary while we support dual kotlin versions

[ZacSweers]

After talking with @Egorand, plan is option A. It's already merged in KotlinPoet and I'll update this after that release is out

[ZacSweers]

woo!

[swankjesse]

LGTM