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

Kotlin の再現例と java/field-masks-super-field クエリから始め、次に Kotlin Live Literals に関する PR #10859 とその処理を比較します。sealed class、object subclasses、open val parameters が Java extractor によってどのように表現されるかを確認してください。このパターンでは alert が抑制され、真正な field shadowing は引き続き報告されれば完了です。

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.