C++: Resolve typedefs when matching MaD parameters

[MathiasVP]

The various implementations of the STL differ on the exact name of the types of some of the parameters. For example, some implementations specify std::vector::insert as:

template<typename T /*, ... */>
class vector {
  /* ... */
  iterator insert(const_iterator, const T&);
}

while others do this instead:

template<typename T /*, ... */>
class vector {
  /* ... */
  iterator insert(const_iterator, const value_type&);
}

these are completely identical since containers are required to declare value_type as a synonym for T. However, until this PR we would match the parameter type name against whatever type name is specified. With the current MaD models, this meant we only matched against the implementations that picked const T&, but not the ones that picked const value_type&.

This PR fixes this by allowing both the unresolved and the typedef-resolved type name. This ensures that we can continue to use the typedef'ed name when it's convenient (for example, when a parameter must have type size_type which is platform dependent).

Our Type class actually comes with a perfectly reasonable predicate for resolving typedefs while retaining whatever specifiers are attached to the type:

codeql/cpp/ql/lib/semmle/code/cpp/Type.qll

Lines 279 to 284 in f23e56b

	* Gets this type with any typedefs resolved. For example, given
	* `typedef C T`, this would resolve `const T&` to `const C&`.
	* Note that this will only work if the resolved type actually appears
	* on its own elsewhere in the program.
	*/
	Type resolveTypedefs() { result = this }

However, as noted by the QLDoc this predicate only has a result when the resulting type (i.e., the typedef-resolved type with the same specifiers) exists in the database. So to get around this we have to create our own predicate for resolving typedefs while retaining the specifiers.

Commit-by-commit review recommended:

• 5ccc12c adds a failing testcase
• 3d3feb6 resolves typedefs
• 682dd42 accepts testcases
• 9672af3 adds a nice small performance optimization I spotted while working on this PR

[Copilot]

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

Files not reviewed (6)

• cpp/ql/lib/semmle/code/cpp/dataflow/ExternalFlow.qll: Language not supported
• cpp/ql/test/library-tests/dataflow/models-as-data/FlowSummaryNode.expected: Language not supported
• cpp/ql/test/library-tests/dataflow/models-as-data/SummaryCall.expected: Language not supported
• cpp/ql/test/library-tests/dataflow/models-as-data/testModels.qll: Language not supported
• cpp/ql/test/library-tests/dataflow/models-as-data/tests.cpp: Language not supported
• cpp/ql/test/library-tests/dataflow/taint-tests/test_mad-signatures.expected: Language not supported

Tip: Copilot only keeps its highest confidence comments to reduce noise and keep you focused. Learn more

[geoffw0]

LGTM, some very minor corrections.

[geoffw0]

I'm trying to convince myself ArrayType doesn't need to be a special case here. Because getName already handles it adequately???

[MathiasVP]

We could add ArrayType as well. I didn't bother with it because very very few parameters are actually declared as array types (since they decay to pointers anyway). But we can add them just to be safe in case we ever want to model some strange function that has an array as a parameter.

[geoffw0]

Might be better to address it now and avoid surprises in future then - but I don't feel strongly about this.

[MathiasVP]

Fixed in a follow-up PR: #18416

[geoffw0]

👍