Support non-heap allocated flexible arrays #6661
Conversation
tautschnig
force-pushed
the
bugfixes/flexible-array-static
branch
from
a31b08c to
da76ab4
Compare
Codecov Report
@@ Coverage Diff @@
## develop #6661 +/- ##
===========================================
+ Coverage 76.92% 77.10% +0.17%
===========================================
Files 1583 1582 -1
Lines 183314 182663 -651
===========================================
- Hits 141018 140834 -184
+ Misses 42296 41829 -467
Continue to review full report at Codecov.
|
tautschnig
force-pushed
the
bugfixes/flexible-array-static
branch
from
da76ab4 to
4965d64
Compare
This addresses an existing todo in the code base: we need to come up with a new type based on the actual initializer. Fixes: diffblue#3653, diffblue#4206 Co-authored-by: Chengyu Zhang <[email protected]> Co-authored-by: Andreas Tiemeyer <[email protected]>
tautschnig
force-pushed
the
bugfixes/flexible-array-static
branch
from
4965d64 to
b16c7d7
Compare
| init_array.type() = actual_array_type; | ||
|
|
||
| // mimic bits of typecheck_compound_type to produce a new struct tag | ||
| actual_struct_type.remove(ID_tag); |
There was a problem hiding this comment.
Mildly a shame to have to mimic/duplicate bits of code... but maybe lifting out the duplicated parts into utilities is even messier if the mimicking isn't complete duplication.
There was a problem hiding this comment.
I did wonder, but cutting out just this bit seemed like it would create a utility function that can only be used in very peculiar circumstances.
| to_array_type(actual_struct_type.components().back().type()); | ||
| actual_array_type.size() = from_integer( | ||
| init_array.operands().size(), actual_array_type.index_type()); | ||
| actual_array_type.set(ID_C_flexible_array_member, true); |
There was a problem hiding this comment.
Any point in introducing a to_C_flexible_array_type or something to make this a bit more structured? I always get a bit nervous when there's a bunch of setup being done in non-constructor/utility function code :-)
There was a problem hiding this comment.
I think the main reason for this being messy is that it adjusts an existing type. So I'll leave it as is for now.
This addresses an existing todo in the code base: we need to come up
with a new type based on the actual initializer.
Fixes: #3653