Files
moshi/moshi-kotlin-codegen
Chris Povirk c9c9f9d838 Insert !! to make some types in generated code non-nullable.
Hi, Square folks.

The background here is that we're working to put nullness annotations on
more "JDK classes," such as `java.lang.Class`, at least in Google's
build system. That means that calls to methods like
`clazz.getMethod(...)` and `clazz.getDeclaredConstructor` must pass
non-nullable `Class` instances. If they don't, we see errors:

```
error: type mismatch: inferred type is Class<Int>? but Class<*> was expected
          String::class.java, String::class.java, Int::class.javaPrimitiveType, String::class.java,
                                                  ^
```

```
error: type mismatch: inferred type is Class<Int>? but Class<*> was expected
          String::class.java, FooResponse::class.java, Int::class.javaPrimitiveType,
                                                       ^
```

```
error: type mismatch: inferred type is Class<CapturedType(*)>? but Class<*> was expected
          Util.DEFAULT_CONSTRUCTOR_MARKER).also { this.constructorRef = it }
          ^
```

Expressions like `Int::class.javaPrimitiveType` are always non-nullable,
so we can use `!!` (or `checkNotNull` or whatever you might prefer)
there without risk.

(Note that it would be possible to avoiding using `!!` for
`INT_TYPE_BLOCK`: We could do so by passing `Integer.TYPE`. The more
general case of `TypeName.asTypeBlock` could theoretically be handled
similarly but would likely require maintaining a mapping from Kotlin
type name to Java primitive wrapper class.)

As for `DEFAULT_CONSTRUCTOR_MARKER`, I haven't looked at the generated
code enough to prove that it's non-nullable here. But if I'm reading the
bytecode right, the property value is being passed to
`getDeclaredConstructor`, so I'd expect NPE there if it were null.

Let me know what you think. I could check with our internal Moshi owners
about maintaining this as a Google-local patch if that's better, but I'm
hoping that this is a fairly harmless change, and our research so far
suggests that we _probably_ won't be back soon to ask about other
changes for this nullness work.
2023-08-30 11:31:50 -04:00
..