False Negative: ContainsTypeMismatch.ql misses mismatched collection lookups once the receiver is routed through a raw alias.

Commencez par le checker Likely Bugs/Collections/ContainsTypeMismatch.ql et le cas PosCase5_Var5.java décrit dans l’issue. Suivez comment le récepteur Vector est récupéré après son affectation à rawVec, puis ajoutez ou mettez à jour un test de régression afin que rawVec.lastIndexOf(arg) soit signalé comme une incompatibilité entre Byte et Float.

False Negative: ContainsTypeMismatch.ql misses mismatched collection lookups once the receiver is routed through a raw alias.

Version
codeql 2.24.3

Checker

• Checker id: Likely Bugs/Collections/ContainsTypeMismatch.ql
• Checker description: This checker detects calls to Java collection methods where the argument type is incompatible with the collection's element type, such as calling contains with an argument that can never match any element in the collection.

Description of the false negative

The collection still holds Byte values and the lookup still uses a Float. The only change is that the call goes through a raw alias before reaching lastIndexOf(...).

That should not be enough to hide the type mismatch from Likely Bugs/Collections/ContainsTypeMismatch.ql.

Affected test cases

PosCase5_Var5.java

rawVec.lastIndexOf(arg) is still searching a Vector<Byte> with a Float. The raw alias obscures generics, but it does not make the lookup compatible.

// Call lastIndexOf on a Vector<Byte> with an argument of type Float (first argument) should be flagged as incompatible type.
package scensct.var.pos;

import java.util.Vector;

public class PosCase5_Var5 {
    public static void main(String[] args) {
        Vector<? extends Byte> vec = new Vector<Byte>();
        // Wildcard capture: still Vector<Byte> compatible
        Float arg = 3.14f;
        // Raw type manipulation to obscure but preserve generic info
        Vector rawVec = vec;
        // Checker must still detect Byte vs Float incompatibility
        rawVec.lastIndexOf(arg);
    }
}

Cause analysis

This looks like a generic-type recovery gap. Once the receiver is widened to a raw type, the query appears to stop using the element type information from the original collection.

That is too weak for this rule. Raw aliases are common in older Java code, and they do not change the fact that a Float can never match an element from a Vector<Byte>.

References

None known.