Weird(?) behavior of `Expr.getType`

[hugeh0ge]

Hello,
I'm not sure if this place is relevant to post this topic(I'm sorry if not), but
I can't see what is going on with the below snippet:

import cpp

class Set1 extends FunctionCall {
  Set1() { this.getNumberOfArguments() >= 1 and exists(Expr e | 1 = 1 | this.getArgument(0) = e) }
}
class Set2 extends FunctionCall {
  Set2() { this.getNumberOfArguments() >= 1 and exists(Type t | 1 = 1 | this.getArgument(0).getType() = t) }
}
from FunctionCall fc
where fc instanceof Set1 and (not fc instanceof Set2)
select fc

I was writing some simple query, which checks the type of the arguments of a certain sort of function calls.
But I realized that for some reason calling getType() narrows the result, regardless of any further operations.
My understanding is that FunctionCall.getArgument(0) always returns Expr as long as the number of arguments is greater than 0, and that Expr.getType() always returns some meaningful instance of Type.
Is this assumption wrong? Or is this a bug or something?

I tested the snippet in some projects including flatbuffers and glibc. In both, we can see that there are some function calls satisfying the condition(they are mostly calls of struct operator and __builtin_function, but I saw other types of function calls in a confidential project).

[MathiasVP]

Thanks for reporting this!

Unfortunately, it's not uncommon that some expressions are missing type information (or even that some expressions have multiple types) due to subtle violations of One Definition Rule.

With that said, the missing types in glibc all seem to be from __builtin* functions, and it's certainly unexpected that these are missing type information. I've made the @github/codeql-c-extractor team aware of this issue.

The missing types in flatbuffers seem to mostly be related to iterators, which is something we've seen before. I've added a link to your report in the ongoing issue where we track this.