C++: support for designated initializers

[nickrolfe]

I've added new tuples to associate aggregate literals, their initializer expressions, and the field or element index being initialized.

This will need to be merged in sync with the internal extractor PR.

This PR also includes the comment-only dbscheme changes from #18, to avoid an extra upgrade script.

[rdmarsh2]

Can we get a test with out-of-order designated initializers? Something like someStruct {.j = 1, .i = 2}. I'd also like to see a test of how this interacts with child ordering; before this PR, designated struct initializers led to creating two children for each initializer.

[nickrolfe]

@rdmarsh2 for your first request, I think the initializers on lines 63-64 of aggregate_literals.c show the right output:

| aggregate_literals.c:62:13:65:7 | {...} | aggregate_literals.c:6:8:6:22 | someOtherStruct | aggregate_literals.c:7:9:7:9 | a | aggregate_literals.c:64:14:64:16 | ... / ... |
| aggregate_literals.c:62:13:65:7 | {...} | aggregate_literals.c:6:8:6:22 | someOtherStruct | aggregate_literals.c:8:9:8:9 | b | aggregate_literals.c:63:14:63:16 | ... * ... |

For your request about child ordering, can you expand on what sort of query you'd like to see? (I think I can explain the problem you saw, and it should now be fixed, but I'm happy to improve the test).

[rdmarsh2]

Those initializers look right; missed it on my first read through.

The queries I was observing issues with were:

from ClassAggregateLiteral cal, int i
select cal, cal.getType().getUnspecifiedType(), i, cal.getChild(i)

and

from ClassAggregateLiteral cal, int i, Field f
where cal.getFieldExpr(f) = cal.getChild(i)
select cal, cal.getType().getUnspecifiedType(), i, cal.getChild(i), f

[jbj]

@dave-bartolomeo can you have a look to ensure that the extracted data is suitable for IR translation?

[nickrolfe]

I've added some tests to show that the child expressions of an aggregate literal are in the correct order (and match the correct fields/array elements).

[ian-semmle]

This should be aggregate_field_init(underlyingElement(this), unresolveElement(result), unresolveElement(field))

[ian-semmle]

Similarly here

[dave-bartolomeo]

Based on your tests, it appears that for an initialization where the order of the designators in the source code does not match the declaration order of the fields, the order of the children in the AggregateLiteral will match the order of the init expression in the source code, not field declaration order, right? The C standard leaves the order of evaluation unspecified, and all three major compilers actually emit the initialization in field declaration order. Do we want the child order to match the source, or to match the order of evaluation?
My guess is that we should do whatever we do for constructor init lists, which have the same issue.

[ian-semmle]

We already know the field declaration order, but the source code order is extra information that is potentially useful.

[nickrolfe]

the order of the children in the AggregateLiteral will match the order of the init expression in the source code, not field declaration order, right?

Right.

I was going to make the same point as @ian.

Also, changing the order of the child exprs would be a largely orthogonal extractor change to the ones made to support designated initializers. I'm sure we could do it, but I'd like to get this PR merged first (especially since the 1.18 deadline is looming).

[dave-bartolomeo]

LGTM

FWIW, constructor init lists seem to show up in field declaration order, regardless of init list order.

The IR currently ignores child order, and sorts initializers by field declaration order, so this change shouldn't impact the IR. Even if it did, the IR is easier to change after feature freeze than the extractor.

I assume I shouldn't approve this until the extractor change goes into the private repo?

[nickrolfe]

Approval is harmless, but it should only be merged at the same time as the private PR.

BTW, should I add a release note?

[jbj]

Yes, definitely add a release note for this change and also other user-visible extractor features added for 1.18. #24 probably qualifies and maybe also the support for _FloatN and _FloatNx.