C++: Prepare for model generation adoption

[MathiasVP]

This PR does the necessary changes to existing C++ code required for model generation. It should be a no-opt in terms of results and performance.

DCA was uneventful (as expected).

[Copilot]

Copilot wasn't able to review any files in this pull request.

Files not reviewed (4)

• cpp/ql/lib/semmle/code/cpp/dataflow/ExternalFlow.qll: Language not supported
• cpp/ql/lib/semmle/code/cpp/ir/dataflow/internal/DataFlowPrivate.qll: Language not supported
• cpp/ql/lib/semmle/code/cpp/ir/dataflow/internal/DataFlowUtil.qll: Language not supported
• cpp/ql/lib/semmle/code/cpp/ir/dataflow/internal/TaintTrackingUtil.qll: Language not supported

[tausbn]

Two typos, otherwise this looks okay to my (relatively untrained on this codebase) eyes.

[tausbn]

Where/how will canonical be used? I only see this predicate used with a wildcard argument for that parameter in this PR.

[MathiasVP]

Your observation is correct! Currently, we're fairly lenient in with the parameter names we accept when mapping a MaD representation to the targeted function. For example:

using MyIntType = int;
void f(MyIntType t);

will both match the parameter list (int) and (MyIntType) (because, annoyingly, some implementations of the C++ standard library differ on whether they use an internal typedef'd name, and what that internal typedef is even called).

However when we want to generate a MaD row (i.e., what model generation will be doing) we don't want to map a function to many parameter lists. So:

• When we consume MaD rows we will always use _ for the canonical parameter (because we want to accept many possible names for the parameter type), but
• When we produce MaD rows we need to pick 1 parameter type name. So when this PR is merged I'll open the PR that actually adds the model generation, and this library will use true for canonical.