Fix array compound literal parsing #309

lorettayao · 2025-10-06T13:22:56Z

Summary
Fix a segfault when evaluating array compound literals like (int[]){1,2,3,4,5} in expression context. The literal now yields the temporary array’s address (via decay) instead of collapsing to a single element, so indexing and reads work correctly.

Motivation
Previously, code like the snippet below crashed because the array literal was reduced to a scalar and later treated as a pointer.

Reproduction (manual)

#include <stdio.h>

int main(void) {
    int *a = (int[]){1,2,3,4,5};   // used to crash later
    printf("Testing basic array compound literal:\n");
    for (int i = 0; i < 5; i++)
        printf("  a[%d] = %d\n", i, a[i]);

    int sum = a[0] + a[4];
    printf("Sum = %d (expect 6)\n", sum);
    return 0;
}

Before: segfault
After: prints a[0..4] and Sum = 6 as expected

Approach (high level)

Ensure (type[]){…} produces a real temporary array object and the expression value decays to its address.
Only collapse to a scalar when a scalar is actually required by context.
No changes to struct compound literals or plain scalars.

Scope

This PR addresses the array side of Fix compound literals to capture all field values, not just first #299 sufficient to eliminate the segfault in basic use.
Struct compound literals and broader initializer behaviors are intentionally out of scope here.

Tests

No test files are added in this PR. The manual snippet above demonstrates the fix.

Compatibility

Restores standard pointer semantics for array compound literals.
No behavioral changes for structs or scalars.

Issue

Partially addresses Fix compound literals to capture all field values, not just first #299 (array compound literals).

Summary by cubic

Fix parsing of array compound literals so they allocate a temporary array and decay to its address, preserving pointer semantics and preventing segfaults.

Bug Fixes
- Eliminates crashes when using (int[]){...} in expressions, assignments, and parameter passing.
- Correct behavior across binary ops, ternary results, and function-call arguments.
- Zero-length array literals yield 0 for scalar uses to avoid garbage reads.
- Addresses Fix compound literals to capture all field values, not just first #299.
Refactors
- Added parse_array_compound_literal and scalarize_array_literal to centralize handling; scalarize only when a scalar is required.
- Emits element writes and counts initializers; tracks brace consumption to avoid double reads.
- Struct and scalar compound literals remain unchanged.

^{Written for commit b13f5b6. Summary will update automatically on new commits.}

Implement proper array compound literal handling that emits element writes, counts initializers, and returns the temporary array pointer instead of collapsing to the first element. This restores correct pointer semantics and avoids discarding array literals during parsing. Struct and scalar compound literals are unchanged. The parser now tracks whether the closing brace was already consumed by the array helper to prevent double reads.

Introduce helpers to centralize array-literal scalar decay. Temporary array compound literals are detected and converted to a scalar only when a scalar is actually required; otherwise the expression yields the temporary array’s address, preserving pointer semantics. Update binary ops, direct/compound assignments, function-call arguments, and ternary results to use the unified helper instead of ad-hoc collapsing. This fixes cases where array literals were reduced to their first element in pointer contexts, while keeping struct and plain scalar behavior unchanged. Addresses sysprog21#299 (array compound literals).

jserv · 2025-10-06T14:02:23Z

src/parser.c

+    }
+    lex_expect(T_close_curly);
+    var->array_size = count;
+}


Add a new blank line.

DrXiao

Add some test cases to the test suite for validation.

jserv

Don't use static qualifier since shecc does not support. Check 'COMPLIANCE.md' carefully.

src/parser.c

jserv · 2025-10-06T14:07:42Z

You MUST ensure bootstrapping is fully functional before submitting pull requests.

visitorckw · 2025-10-06T14:34:14Z

IIUC, compound literals are a feature supported only since C99, and the shecc README mentions from the very beginning that this project aims to support ANSI C. Therefore, IMO, this at least does not "fix" anything.

DrXiao · 2025-10-06T14:49:42Z

IIUC, compound literals are a feature supported only since C99, and the shecc README mentions from the very beginning that this project aims to support ANSI C. Therefore, IMO, this at least does not "fix" anything.

As far as I know, shecc is planned to fully support the C99 standard, so I think the term "fix" is acceptable.

visitorckw · 2025-10-06T14:53:37Z

Fine, but since we haven't claimed to fully support C99 and, IIUC, array compound literals were never supported before, this seems more like supporting a new feature to me, rather than fixing an existing problem.

DrXiao · 2025-10-06T15:10:25Z

In fact, shecc has ability to handle array compound literals, but it only captures the first element (#299).

Therefore, this pull request specifically aims to fix it.

visitorckw · 2025-10-06T15:21:20Z

In fact, shecc has ability to handle array compound literals, but it only captures the first element (#299).

Therefore, this pull request specifically aims to fix it.

Thanks, that resolves my doubt.
However, should we also mention the issue in the first commit?

src/parser.c

jserv

Don't add tests/array_ptr.c. Instead, consolidate tests/driver.sh.

visitorckw

Please rebase your branch to keep the git history clean.
Commits that fix problems introduced within the same pull request should be avoided.

jserv · 2025-10-08T13:20:34Z

src/parser.c

+
+    add_insn(parent, *bb, OP_read, scalar, array_var, NULL, elem_size, NULL);
+    return scalar;
+}


Add a line break.

cubic-dev-ai · 2025-11-07T12:08:23Z

Looking at the changes, the core logic for handling array compound literals looks solid—good job centralizing the decay behavior to avoid ad-hoc fixes everywhere. But yeah, there are some style inconsistencies and comment opportunities that could make this even tighter. Here's what I'd suggest, focused on parser.c (the bulk of the changes) and the test additions. I'll keep it practical: specific line tweaks for consistency with the rest of the codebase (e.g., brace placement, naming, spacing) and punchier comments.

Style Fixes for `parser.c`

Brace placement and indentation in new functions:

In parse_array_compound_literal, the if (!lex_peek(T_close_curly, NULL)) block has inconsistent indentation for the inner for loop—align it to match the function's style (2-space indents). Also, add braces around single-statement blocks for consistency (e.g., the count++ line).

if (!lex_peek(T_close_curly, NULL)) {
    for (;;) {
        read_expr(parent, bb);
        read_ternary_operation(parent, bb);
        var_t *value = opstack_pop();
        if (count == 0)
            var->init_val = value->init_val;
        if (emit_code) {
            // ... (existing code)
        }
        count++;  // Add braces if expanding later
        if (!lex_accept(T_comma))
            break;
        if (lex_peek(T_close_curly, NULL))
            break;
    }
}

This matches the style in read_expr and avoids future bugs.

Variable naming consistency:
- vd is overused as a generic var_t pointer—rename to something descriptive in read_ternary_operation (e.g., result_var for the final vd). It's clear in context, but vd feels like a holdover from declarations elsewhere.
```
var_t *result_var = require_var(parent);
gen_name_to(result_var->var_name);
add_insn(parent, then_, OP_assign, result_var, true_val, NULL, 0, NULL);
add_insn(parent, else_, OP_assign, result_var, false_val, NULL, 0, NULL);
// ...
result_var->is_ternary_ret = true;
opstack_push(result_var);
```
- Similarly, in read_body_assignment, rhs_val and rhs are redundant—use rhs consistently and drop the intermediate.
Spacing and operator alignment:
- In is_array_literal_placeholder, tighten the return condition: return var && var->array_size > 0 && !var->ptr_level && var->var_name[0] == '.';
- In binary op handling (around line 2908), the new rs1_is_ptr_like checks have good logic but uneven spacing—align the bool defs:
```
bool rs1_is_ptr_like = rs1 && (rs1->ptr_level || rs1->array_size);
bool rs2_is_ptr_like = rs2 && (rs2->ptr_level || rs2->array_size);
```
- Remove extra blank lines after function defs (e.g., after scalarize_array_literal) to match the compact style in the original parser.
Minor: Unused params and locals:
- In scalarize_array_literal, hint_type defaults to TY_int if invalid, but the null check for elem_type could be simplified: type_t *elem_type = hint_type ? hint_type : array_var->type ? array_var->type : TY_int;. Drops the nested if.
- var->init_val = 0; in a few spots (e.g., zero-length handling) is fine, but ensure it's set consistently—it's already good, just a nit.

Comment Improvements

The inline comments are mostly helpful, but some are wordy or could be more precise. Aim for concise, factual notes that explain why not just what.

Update the placeholder comment (around line 1364):
- Current: "Identify compiler-emitted temporaries that hold array compound literals. Parsing assigns these temporaries synthetic names via gen_name_to (".tN") and they keep array metadata without pointer indirection."
- Suggested: "Detect compiler temporaries ('.tN' names) holding array compound literals. These retain array metadata (size/type) without decaying to pointers until needed."
  - Shorter, focuses on the key invariant (no auto-decay).

Add a brief header comment to parse_array_compound_literal:

/* Parse array compound literal contents: emit element stores to a temporary array.
 * Counts initializers and consumes the closing brace. Used only for array types. */
void parse_array_compound_literal(var_t *var, /* ... */)

Explains purpose without repeating the PR description.

Clarify scalarization calls:
- In function params (around line 1650), add: // Decay array literals to scalars for non-pointer params, per C semantics.
- In ternary handling: // Scalarize array literals if the other branch isn't pointer-like, to match types.
- In assignment: // Decay RHS array literal to scalar if target is non-pointer (e.g., int x = (int[]){1}; uses first elem).
  - These tie back to the motivation (avoiding scalar collapse in pointer contexts) without verbosity.
Zero-length handling (in read_expr_operand):
- Current implicit via if (compound_var->array_size == 0). Add: // Zero-length arrays default to 0 constant (avoids garbage reads in scalar contexts).

For Tests in `driver.sh`

The new tests are great for coverage, but add a comment block at the top of the array sections:
```
# Array compound literal tests: verify decay to pointer in assignments and args
```
In the sum test, the 0, 0 padding is clever for partial init, but add an expected output comment: # Expects sum=6 from first 3 elements.
Consistent with existing tests: Use try_ 0 everywhere (you did), and keep EOF indents clean.

These tweaks keep the code readable and maintainable without overhauling anything. Total changes: ~20 lines. Run a style check (assuming you have one) after, and it'll align nicely with the rest of the parser. If you push an updated commit, I can re-review the diffs.

jserv · 2025-11-14T08:27:22Z

I defer to @ChAoSUnItY for confirmation.

ChAoSUnItY · 2025-11-14T16:09:47Z

src/arm-codegen.c

            fatal("Unsupported truncation operation with invalid target size");
        }
        return;
-    case OP_sign_ext: {


Why removing the curly braces while this case branch has variable declaration?

I didn’t really mean to drop those braces—they were just left behind while trying other tweaks. but it’s fine either way because C99 lets us declare source_size right after the case label without changing behavior.

Yes, although C99 allows this. But since in our compiler's standard workflow, stage 0 will be compiled by GCC with -Wpedantic compilation option included, and this will cause building process to output warning even in this case it didn't do anything in a harmful way.

I reverted it to the original order in my latest commit

ChAoSUnItY · 2025-11-15T08:37:31Z

src/parser.c

                    var_t *expr_result = opstack_pop();

-                    /* Handle array compound literal to scalar assignment.
-                     * When assigning array compound literals to scalar
-                     * variables, use the first element value rather than array
-                     * address.
-                     */
-                    if (expr_result && expr_result->array_size > 0 &&
-                        !var->ptr_level && var->array_size == 0 && var->type &&
-                        (var->type->base_type == TYPE_int ||
-                         var->type->base_type == TYPE_short) &&
-                        expr_result->var_name[0] == '.') {
-                        var_t *first_elem = require_var(parent);
-                        first_elem->type = var->type;
-                        gen_name_to(first_elem->var_name);
-
-                        /* Extract first element from compound literal array */
-                        add_insn(parent, bb, OP_read, first_elem, expr_result,
-                                 NULL, var->type->size, NULL);
-                        expr_result = first_elem;
-                    }
+                    var_t *rhs = expr_result;
+                    if (!var->ptr_level && var->array_size == 0)


How about:

var_t *rhs = opstack_pop();

squashed together in the latest commit!

src/parser.c

Fix IR test failure. Regenerate ARM IR snapshots to reflect the corrected lowering. Restore ARM/RISC-V codegen files to original structure after earlier brace experiment. Treat zero-length array compound literals as constant zero during lowering so scalar uses don't load garbage. Fix coding style for parser.c according to cubic's suggestion. Ignore comment modification in tests/driver.sh

cubic-dev-ai

1 issue found across 7 files

Prompt for AI agents (all 1 issues)


Understand the root cause of the following 1 issues and fix them.


<file name="src/parser.c">

<violation number="1" location="src/parser.c:1660">
Variadic call arguments shouldn’t be scalarized—array compound literals must still decay to pointers when passed through `...`, otherwise the callee receives the first element value instead of the array address and pointer-based code crashes.</violation>
</file>

_{Reply to cubic to teach it or ask questions. Re-run a review with @cubic-dev-ai review this PR}

cubic-dev-ai · 2025-11-18T15:00:46Z

src/parser.c

+                    param = scalarize_array_literal(parent, bb, param,
+                                                    target->type);
+            } else if (func->va_args) {
+                param = scalarize_array_literal(parent, bb, param, TY_int);


Variadic call arguments shouldn’t be scalarized—array compound literals must still decay to pointers when passed through ..., otherwise the callee receives the first element value instead of the array address and pointer-based code crashes.

Prompt for AI agents

Address the following comment on src/parser.c at line 1660: <comment>Variadic call arguments shouldn’t be scalarized—array compound literals must still decay to pointers when passed through `...`, otherwise the callee receives the first element value instead of the array address and pointer-based code crashes.</comment> <file context> @@ -1575,7 +1650,16 @@ void read_func_parameters(func_t *func, block_t *parent, basic_block_t **bb) + param = scalarize_array_literal(parent, bb, param, + target->type); + } else if (func->va_args) { + param = scalarize_array_literal(parent, bb, param, TY_int); + } + } </file context>

cubic-dev-ai

2 issues found across 7 files

Prompt for AI agents (all 2 issues)


Understand the root cause of the following 2 issues and fix them.


<file name="src/parser.c">

<violation number="1" location="src/parser.c:1344">
`scalarize_array_literal` reads using the destination type’s width, so assigning a `(short[])` literal to an `int` pulls 4 bytes, mixing multiple elements and producing incorrect values. The read width must match the literal’s element size.</violation>

<violation number="2" location="src/parser.c:2914">
Array literals are scalarized whenever the other operand isn’t pointer-like, so `(int[]){…} + 1` yields a scalar sum instead of pointer arithmetic. Pointer operators need the literal to remain pointer-like; don’t collapse it solely because the opposing operand is an integer.</violation>
</file>

_{Reply to cubic to teach it or ask questions. Re-run a review with @cubic-dev-ai review this PR}

cubic-dev-ai · 2025-11-18T15:03:12Z

src/parser.c

+        bool rs1_is_ptr_like = rs1 && (rs1->ptr_level || rs1->array_size);
+        bool rs2_is_ptr_like = rs2 && (rs2->ptr_level || rs2->array_size);
+
+        if (is_array_literal_placeholder(rs1) && !rs2_is_ptr_like)


Array literals are scalarized whenever the other operand isn’t pointer-like, so (int[]){…} + 1 yields a scalar sum instead of pointer arithmetic. Pointer operators need the literal to remain pointer-like; don’t collapse it solely because the opposing operand is an integer.

Prompt for AI agents

Address the following comment on src/parser.c at line 2914: <comment>Array literals are scalarized whenever the other operand isn’t pointer-like, so `(int[]){…} + 1` yields a scalar sum instead of pointer arithmetic. Pointer operators need the literal to remain pointer-like; don’t collapse it solely because the opposing operand is an integer.</comment> <file context> @@ -2810,6 +2908,16 @@ void read_expr(block_t *parent, basic_block_t **bb) + bool rs1_is_ptr_like = rs1 && (rs1->ptr_level || rs1->array_size); + bool rs2_is_ptr_like = rs2 && (rs2->ptr_level || rs2->array_size); + + if (is_array_literal_placeholder(rs1) && !rs2_is_ptr_like) + rs1 = scalarize_array_literal(parent, bb, rs1, + rs2 && rs2->type ? rs2->type : NULL); </file context>

cubic-dev-ai · 2025-11-18T15:03:12Z

src/parser.c

+    if (!is_array_literal_placeholder(array_var))
+        return array_var;
+
+    type_t *elem_type = hint_type ? hint_type : array_var->type;


scalarize_array_literal reads using the destination type’s width, so assigning a (short[]) literal to an int pulls 4 bytes, mixing multiple elements and producing incorrect values. The read width must match the literal’s element size.

Prompt for AI agents

Address the following comment on src/parser.c at line 1344: <comment>`scalarize_array_literal` reads using the destination type’s width, so assigning a `(short[])` literal to an `int` pulls 4 bytes, mixing multiple elements and producing incorrect values. The read width must match the literal’s element size.</comment> <file context> @@ -1283,6 +1286,78 @@ void parse_array_init(var_t *var, + if (!is_array_literal_placeholder(array_var)) + return array_var; + + type_t *elem_type = hint_type ? hint_type : array_var->type; + if (!elem_type) + elem_type = TY_int; </file context>

lorettayao added 2 commits October 6, 2025 19:51

This comment was marked as outdated.

Sign in to view

jserv reviewed Oct 6, 2025

View reviewed changes

DrXiao suggested changes Oct 6, 2025

View reviewed changes

jserv requested changes Oct 6, 2025

View reviewed changes

jserv reviewed Oct 6, 2025

View reviewed changes

src/parser.c Outdated Show resolved Hide resolved

Fix formatting, add testcase, remove static

b44dc57

lorettayao added 3 commits October 8, 2025 15:18

Fix misleading function naming

1f7bed4

Fix data format according to warnings

d6b9fbf

add: test case for array compound literals

272c912

jserv reviewed Oct 8, 2025

View reviewed changes

src/parser.c Outdated Show resolved Hide resolved

jserv requested changes Oct 8, 2025

View reviewed changes

Change function name and remove test case

accfedf

visitorckw suggested changes Oct 8, 2025

View reviewed changes

jserv reviewed Oct 8, 2025

View reviewed changes

This comment was marked as resolved.

Sign in to view

sysprog21 deleted a comment from cubic-dev-ai bot Nov 7, 2025

This comment was marked as resolved.

Sign in to view

lorettayao force-pushed the fix-array-init branch from bf5f3d0 to b88294c Compare November 7, 2025 11:55

sysprog21 deleted a comment from cubic-dev-ai bot Nov 7, 2025

lorettayao force-pushed the fix-array-init branch from b88294c to 0de5d30 Compare November 9, 2025 08:38

lorettayao force-pushed the fix-array-init branch from 0de5d30 to 08f1e29 Compare November 9, 2025 09:41

jserv requested a review from ChAoSUnItY November 14, 2025 08:26

ChAoSUnItY reviewed Nov 15, 2025

View reviewed changes

lorettayao force-pushed the fix-array-init branch from 08f1e29 to b13f5b6 Compare November 18, 2025 09:14

sysprog21 deleted a comment from cubic-dev-ai bot Nov 18, 2025

cubic-dev-ai bot reviewed Nov 18, 2025

View reviewed changes

Fix array compound literal parsing #309

Are you sure you want to change the base?

Fix array compound literal parsing #309

Conversation

lorettayao commented Oct 6, 2025 • edited by cubic-dev-ai bot Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary by cubic

Uh oh!

This comment was marked as outdated.

Uh oh!

jserv Oct 6, 2025

Choose a reason for hiding this comment

Uh oh!

DrXiao left a comment

Choose a reason for hiding this comment

Uh oh!

jserv left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

jserv commented Oct 6, 2025

Uh oh!

visitorckw commented Oct 6, 2025

Uh oh!

DrXiao commented Oct 6, 2025

Uh oh!

visitorckw commented Oct 6, 2025

Uh oh!

DrXiao commented Oct 6, 2025

Uh oh!

visitorckw commented Oct 6, 2025

Uh oh!

Uh oh!

jserv left a comment

Choose a reason for hiding this comment

Uh oh!

visitorckw left a comment

Choose a reason for hiding this comment

Uh oh!

jserv Oct 8, 2025

Choose a reason for hiding this comment

Uh oh!

This comment was marked as resolved.

Uh oh!

This comment was marked as resolved.

Uh oh!

cubic-dev-ai bot commented Nov 7, 2025 • edited by jserv Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Style Fixes for parser.c

Comment Improvements

For Tests in driver.sh

Uh oh!

jserv commented Nov 14, 2025

Uh oh!

ChAoSUnItY Nov 14, 2025

Choose a reason for hiding this comment

Uh oh!

lorettayao Nov 18, 2025

Choose a reason for hiding this comment

Uh oh!

ChAoSUnItY Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lorettayao Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ChAoSUnItY Nov 15, 2025

Choose a reason for hiding this comment

Uh oh!

lorettayao Nov 18, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

cubic-dev-ai bot left a comment

Choose a reason for hiding this comment

Uh oh!

cubic-dev-ai bot Nov 18, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

lorettayao commented Oct 6, 2025 •

edited by cubic-dev-ai bot

Loading

cubic-dev-ai bot commented Nov 7, 2025 •

edited by jserv

Loading

Style Fixes for `parser.c`

For Tests in `driver.sh`

ChAoSUnItY Nov 18, 2025 •

edited

Loading

lorettayao Nov 18, 2025 •

edited

Loading

cubic-dev-ai bot Nov 18, 2025 •

edited

Loading

cubic-dev-ai bot Nov 18, 2025 •

edited

Loading

cubic-dev-ai bot Nov 18, 2025 •

edited

Loading