C++: Fix FP in cpp/uninitialized-local

[MathiasVP]

I was testing something completely different when I came across a result from cpp/uninitialized-local that was very unexpected. On main we currently raise an alert in Joystick.cpp due to the use of not in the following predicate:

DeclStmt declWithNoInit(LocalVariable v) {
  result.getADeclaration() = v and
  not exists(v.getInitializer()) and
  /* The type of the variable is not stack-allocated. */
  not allocatedType(v.getType())
}

because the jinput variable has no result for getType(). This PR fixes that FP.

[geoffw0]

Change LGTM.

Remind me why it's OK for a Variable to have no type. Is it possible for one to have more than one type?

[MathiasVP]

It's never really okay for a variable to have no type. AFAIK, this is always an extractor issue. It's also possible for a variable to have more than one type, which has caused a bunch of problems in the past.

[geoffw0]

I wonder what would happen in a situation where a variable has two types, one of which is 'stack-allocated' and the other of which isn't. It's hard to imagine it coming up. Possibly a forex might be more robust in that situation???

(I think 'stack-allocated' is a poor choice of name by the way; what we're really talking about, I think, is types that can be partially assigned)

[MathiasVP]

It would be more robust, yeah. I think, however, that there are many places where such a change would make things more robust. It might even be better to just leave them as they are, as this gives us a better chance to expose extractor-related issues in the wild.

I also agree that the name could be more precise. Would you prefer if I changed the name to partiallyAssignable or something similar?

[geoffw0]

I prefer partiallyAssignable, but I appreciate you probably have higher priorities than cleaning up this query.

[geoffw0]

Happy with this change as it is though.