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 進行比較。確認 Java extractor 如何表示 sealed class、object subclasses 和 open val parameters。完成的標準是：針對這種模式抑制 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.