C++: Abstractions for treating qualifiers as parameters in IR

[MathiasVP]

Fixes https://github.com/github/codeql-c-analysis-team/issues/186.

In #3571 we made it possible to treat this as an argument, but there are still a couple of places where we need to distinguish between qualifiers and parameters (and between this and arguments). These places are:

• When accessing the arguments supplied to a CallInstruction (which has a getPositionalArgument and getThisArgument predicates)
• When working with instructions that initialize parameters (where initializers of positional parameters have a result for the getParameter predicate, but instructions initializing this need to refer to the IRVariable). The same problem also exists for ReturnIndirectionInstruction.

This PR adds a new predicate for each of these scenarios:

• CallInstruction now has a getPositionalOrThisArgumentOperand (and getPositionalOrThisArgument) predicates that, given an index, gives back the argument operand (and instruction) with the given index, or when the index is -1, gives back the operand used as the qualifier.
• InitializeParameterInstruction and InitializeIndirectionInstruction now have an isParameterOrQualifierIndex predicate that holds if the instruction initializes a positional parameter with a given index, or initialize this with the index -1.
  Similarly, ReturnIndirectionInstruction has a new predicate isParameterOrThisIndirection with similar semantics.

[MathiasVP]

CPP-difference started: https://jenkins.internal.semmle.com/job/Changes/job/CPP-Differences/1563/

[rdmarsh2]

I think we want to guide users towards using these predicates by default, which usually means giving them names that are simpler than their alternatives. Could getPositionalOrThisArgumentOperand just be getArgumentOperand? Similarly, would isParameterOrQualifierIndex be better as hasIndex?

[MathiasVP]

I think we want to guide users towards using these predicates by default, which usually means giving them names that are simpler than their alternatives. Could getPositionalOrThisArgumentOperand just be getArgumentOperand? Similarly, would isParameterOrQualifierIndex be better as hasIndex?

I think those are some excellent names! I've changed the names to match your suggestions now. I had to get rid of an unused predicate on DataFlowCall in DataFlowPrivate since the name was clashing with your suggestion (and I think removing that predicate is okay since I don't think we expect users to use DataFlowCall?)

[MathiasVP]

CPP-difference started: https://jenkins.internal.semmle.com/job/Changes/job/CPP-Differences/1563/

CPP-difference looks good (for some reason there's a 10% reduction in build/extraction/import time on openjdk?)

[jbj]

Looks great! I'm happy with the names too.

[jbj]

The implementation of this predicate looks a lot like getArgumentOperand, but only the latter has pragma[noinline] on it. Is there a good reason to put pragma[noinline] on one but not the other?

[MathiasVP]

Hm, no. I suspect the pragma[noinline] is an artifact of me copy/pasting from getPositionalArgumentOperand. I'll just double-check that I can safely remove the new pragma[noinline]s.

[MathiasVP]

Hm... looking at this comment you made, I'd actually feel more comfortable adding a pragma[noinline] to the hasIndex predicates. It doesn't seem to be necessary right now, but if it avoids a future bad join-order we might as well put it there now. Would that be reasonable?

[jbj]

Yes.