C++: Implement MaD support for flow through perfect-forwarding functions

[MathiasVP]

This PR implements the necessary library changes to support MaD summaries for functions such as vector::emplace_back or make_unique. These functions receive a list of arguments and then forwards them to a constructor call.

@hvitved had a super cool implementation idea. Given:

struct Foo {
  Foo(int);
};

std::vector<Foo> v;

we model a call such as v.emplace_back(42) as:

v.emplace_back(42, &Foo)

and give emplace_back two summaries:

1. Argument[0] -> Argument[1].Parameter[0]
2. Argument[1].Parameter[this] -> Argument[this].Element

The first summary states that 42 goes into the 0'th parameter of the Foo constructor, and the second summary states that the this parameter of the constructed object goes into the this argument of v with an Element content.

(A few lines I told in the above paragraph:

• You cannot take the address of a constructor in C++. But that doesn't mean we cannot use it as an implementation detail!
• We don't actually use the last argument as the argument position of the synthetic function pointer for the constructor. This PR adds a new argument position which we name forward in MaD. I'm happy to change this name to something else if anyone has any strong opinions about this.)

In order to know which constructor to forward to we need to know what type is being constructed. For example:

std::vector<Foo> v;
v.emplace_back(42); // calls `Foo(42)`
v.emplace(v.begin(), 42); // calls `Foo(42)`
std::make_unique<Foo> p(42); // calls `Foo(42)`

To know which type is constructed we add a new extensible called forwardsModel with rows very much like what we have for MaD summaries. For example, I've added this as row as a test:

["", "Container<T>", True, "emplace<Args>", "(Args &&)", "", "0", "T", "manual"]

this says that a call to Container<T>::emplace(args0, ..., argsN) forwards its arguments to a call to T(args0, ..., argsN). The 0 specifies an offset so we can support cases like v.emplace(v.begin(), 42) where we need to ignore the first argument.

This PR doesn't actually add any non-test MaD summaries. I'll delay that to a future PR.

[hvitved]

Overall this approach LGTM; initially I hadn't thought of defining the forwarder models in MaD as well, but if you prefer that it's fine by me.

[hvitved]

AFAICT, there is currently no test case for this?

[MathiasVP]

Uh, good point. Added in dcda06a

[hvitved]

How come these models mention type parameters while the summary models don't?

[MathiasVP]

The type parameters are optional in MaD for C++. In the summary case we don't need them in this case (since we don't specify a signature). In this case we need to refer to the type parameter in the class name since we need to refer to the type being constructed (i.e., T), and we need the type parameter for the function name since we need to specify the signature.

[hvitved]

I also think this branch is not covered by tests?

[MathiasVP]

Fixed in 8149caa

[hvitved]

Holds if `forwarder` may forward its arguments starting at `start` to `constructor`. The
actual constructor being forwarded to depends on the types of arguments from `start`
at calls to `forwarder`.

[MathiasVP]

Thanks! Copy/pasted into f381119

[MathiasVP]

Overall this approach LGTM; initially I hadn't thought of defining the forwarder models in MaD as well, but if you prefer that it's fine by me.

Thanks for the review, Tom! I actually opened a non-draft version of the PR here. Sorry about the confusion!

The code is essentially what's in here (and I've addressed your review comments by pushing changes to that PR). The difference between this PR and the non-draft one is that the non-draft one only requires specifying the forwards model, and then automatically generates the required summary models.

[MathiasVP]

I'll close this PR to avoid further confusion