False Negative: ContradictoryTypeChecks.ql misses impossible subtype checks once the false branch is expressed through aliases or lambdas.

[Carlson-JLQ]

False Negative: ContradictoryTypeChecks.ql misses impossible subtype checks once the false branch is expressed through aliases or lambdas.

Version
codeql 2.24.3

Checker

• Checker id: Likely Bugs/Likely Typos/ContradictoryTypeChecks.ql
• Checker description: This checker detects contradictory type checks where a variable is first checked to be of a supertype via an instanceof guard, and later accessed with a cast or instanceof check for a subtype, which is impossible.

Description of the false negative

Both samples keep the same contradiction: after ruling out a supertype, the code still checks or casts the same value as if it were a subtype of that supertype. One variant hides the contradiction in a lambda branch, and the other splits it across an alias.

That is still exactly the bug Likely Bugs/Likely Typos/ContradictoryTypeChecks.ql is supposed to catch.

Affected test cases

PosCase1_Var3.java

The lambda packaging is incidental. On the false side of obj instanceof CharSequence, the code still performs String s = (String) obj, which remains contradictory.

// A variable is checked with instanceof for a supertype in a guard condition, and on the guard's false path, the same variable is cast to a subtype of that supertype should be flagged as contradictory type check.
package scensct.var.pos;

public class PosCase1_Var3 {
    public static void main(String[] args) {
        Object obj = new Object();
        // Use a ternary operator to choose a path, but keep the cast in the false branch
        Runnable action = (obj instanceof CharSequence) 
            ? () -> { CharSequence cs = (CharSequence) obj; }
            : () -> { String s = (String) obj; }; // Contradictory cast inside lambda
        action.run();
    }
}

PosCase2_Var1.java

Using temp in the guard and obj in the false branch does not change the underlying contradiction. Both names refer to the same object.

// A variable is checked with instanceof for a supertype in a guard condition, and on the guard's false path, the same variable is checked with instanceof for a subtype of that supertype should be flagged as contradictory type check.
package scensct.var.pos;

public class PosCase2_Var1 {
    public static void main(String[] args) {
        Object obj = new Object();
        // Introduce a temporary variable to alias the original
        Object temp = obj;
        // Guard condition on the alias
        if (temp instanceof CharSequence) {
            CharSequence cs = (CharSequence) temp;
        } else {
            // The false branch still refers to the original variable
            if (obj instanceof String) {
                String s = (String) obj;
            }
        }
    }
}

Cause analysis

The query seems too syntax-driven around a single if/else shape. Once the contradictory check is split across aliases or packed into another control-flow construct, the relationship between the guard and the impossible subtype operation is lost.

That makes the rule easier to bypass than it should be. The contradiction is semantic, not stylistic.

References

None known.

[redsun82]

Thanks @Carlson-JLQ. The lambda and alias variants are interesting edge cases. The query currently operates on a fairly rigid control-flow shape, and extending it to track value identity across aliases or into lambdas would be a significant lift. We'll track this but don't expect to prioritize it unless we see this pattern causing confusion in real scans.