NullPointerException in ClassReferenceFixer on unresolved Kotlin metadata references

[ianbrandt]

ClassReferenceFixer's KotlinReferenceFixer assumes every Kotlin metadata reference resolved, and NPEs when one didn't. Several spots dereference the referenced* field without a null check:

// ClassReferenceFixer.java:773  visitAnyType
kotlinTypeMetadata.className = kotlinTypeMetadata.referencedClass.getName();

// :746  visitAnyFunction
kotlinFunctionMetadata.referencedMethod.getName(kotlinFunctionMetadata.referencedMethodClass)

// :905  visitAnyArgument
argument.referencedAnnotationMethod.getName(annotation.referencedAnnotationClass);

// :917 / :929  visitClassArgument / visitEnumArgument
value.className = value.referencedClass.getName();

If the class pool is incomplete — e.g. a class referenced only from @Metadata that isn't on the classpath — ClassReferenceInitializer leaves the matching referenced* null, and these lines throw instead of leaving the reference as-is. (visitAnyType does have a guard, but it's on className != null, not the referencedClass it actually dereferences.)

The annotation path right above already does the right thing:

// :888  visitAnyAnnotation
if (annotation.referencedAnnotationClass != null) {
  annotation.className = annotation.referencedAnnotationClass.getName();
}

Could the type / function / argument paths get the same null guard? Today an incomplete classpath crashes the fixer rather than degrading gracefully.

[ianbrandt]

Opened #176 for this. The five spots listed all reproduced, and the fix mirrors the existing visitAnyAnnotation guard.

I found the same latent NPE in a few siblings that share the root cause (an incomplete class pool leaves referenced* null), so the PR guards all of them, not just the five:

• visitKotlinClassMetadata: enumEntry.referencedEnumEntry.getName(...) (enum entry names)
• visitAnyFunction / visitConstructor: the new MethodSignature(referencedMethodClass, referencedMethod) JVM-signature construction, whose @NotNull constructor dereferences both members
• visitAnyProperty / fixPropertyMethod: the backing-field signature and the accessor/synthetic-method signatures

The newClassName-based paths (nested classes, sealed subclasses, multi-file facade parts) were already null-safe, since that helper returns the name unchanged when the referenced class is null.

Regression tests reproduce the incomplete-classpath scenario (remove a referenced class, reinitialize, run the fixer) for both a dangling type reference and a dangling annotation-argument reference; both throw before the fix and pass after.

[piazzesiNiccolo-GS]

Thanks for the report. We are aware of the issue, which was exposed due to annotations in metadata being stabilized in Kotlin 2.4. We will be handling this as part of the kotlin 2.4 support version update (which is coming soon :)). I will soon have a look at your PRs.