False positive: java/field-masks-super-field triggered on Kotlin sealed class with open val constructor parameters

Start with the Kotlin reproduction and the java/field-masks-super-field query, then compare its handling with PR #10859 on Kotlin Live Literals. Confirm how the sealed class, object subclasses, and open val parameters are represented by the Java extractor. Done means the alert is suppressed for this pattern while genuine field shadowing remains reported.

Summary

The rule java/field-masks-super-field is producing a false positive on a Kotlin sealed class that uses open val constructor parameters. No actual field shadowing exists in the source code.

CodeQL Version

GitHub Advanced Security (cloud) - latest on github.dev

Language

Kotlin (analysed via Java extractor)

Minimal Reproduction

sealed class ImageType(open val width: Int, open val height: Int) {
    object Portrait  : ImageType(78, 98)
    object Square    : ImageType(78, 78)
    object PortraitLarge : ImageType(163, 205)
}

What CodeQL Reports

"This field shadows another field called width/height in a superclass."

Rule ID: java/field-masks-super-field

Why This Is a False Positive

• No subclass redeclares width or height in its body
• Every object subclass simply passes values via the constructor to the parent
• There is no Java-style field shadowing at the source level
• The alert appears to be triggered by synthetic bridge method scaffolding
  that Kotlin generates for open val properties, which the Java extractor
  misidentifies as a field declaration in the subclass

Related

This appears to be in the same category as PR #10859 which excluded Kotlin Live Literals from this same rule:
https://github.com/github/codeql/pull/10859

That PR acknowledged that Kotlin-generated bytecode patterns can trigger false positives in java/field-masks-super-field. The sealed class + object + open val pattern appears to be another such case.

Workaround

Removing open from the constructor parameters eliminates the alert and is safe when no subclass actually overrides the properties. However
this forces unnecessary code changes to work around a false positive.

Expected Behaviour

The rule should not fire when no subclass explicitly redeclares the field in its body - consistent with how PR #10859 handled Live Literals.