Repository navigation
Description
Description of the false positive
java/local-variable-is-never-read reports Kotlin compiler-generated other_with_cast temporaries for zero-property data object declarations. The diagnostic is attached to the Kotlin file without a source region; GitHub displays line1. The application does not declare these variables or an equals implementation.
Environment actually observed
- CodeQL CLI 2.27.3, as selected by
github/codeql-actionv4.39.1 at9b3254085494b55a0f7c4c2b3d2d52cc712ce370. - Kotlin 2.4.21, JVM 27, Java/Kotlin manual build,
security-extendedwith the remote threat model. - The observations below come from a completed Android/Compose analysis and its SARIF, not an independently rerun CodeQL database for the reduced source below.
Reduced source
private sealed interface LoadState {
data object Loading : LoadState
data object Failed : LoadState
}
fun main() {
val states: List<LoadState> = listOf(LoadState.Loading, LoadState.Failed)
states.forEach { println(it) }
}Observed SARIF diagnostic
Rule: java/local-variable-is-never-read
Level: note
Variable 'Loading tmp0_other_with_cast' is never read.
Variable 'Failed tmp0_other_with_cast' is never read.
Physical location: Kotlin source artifact, without a source region
The same analysis reports the same temporary-name pattern for two other zero-property data objects in another Kotlin source file.
Compiler and bytecode evidence
Kotlinv2.4.21 DataClassMembersGenerator.kt creates other_with_cast before iterating through properties. Reads occur within that loop. For a zero-property data object, the compiler-generated local therefore has no property read.
The Kotlin data-object contract specifies generated equals/hashCode implementations and prohibits supplying custom implementations. javap -p -c -l -v on both affected compiled classes confirms that equals(Object) exists despite being absent from application source; its LocalVariableTable contains only this and other after JVM lowering. No application declaration named tmp0_other_with_cast exists.
Expected behavior
Exclude this generated data-object equality temporary from the unread-source-local diagnostic, while retaining detection of genuinely unused user declarations.
Version-check limit
I did not execute a new CodeQL analysis with 2.27.4. Its official query is byte-identical to2.27.3 (UnreadLocal.ql SHA256 aae0d6fd7a2df5291352a3b2597cdff9e92a41f264e413801bb57ffbee071894), and the official Kotlin-extractor source subtree is identical (17c4961985b50180674d18fb4b12d64d3fd36b23). This is not a claim that an upgrade fixes or reproduces the issue; it records the inspected source boundaries.
The application has not been rewritten and the query has not been suppressed. The public example above contains no application-specific code, credentials or private repository references.
Activity
sam-robson commentedon Nov 3, 2026
Thanks for the detailed report @lcv-leo. Resolving this false positive isn’t a current product priority, but we appreciate you flagging it for future consideration.
test: keep CodeQL data-object locals out of the scan