feat: parser-level support for block literals and __block variables by dotcarmen · Pull Request #971 · Vexu/arocc

dotcarmen · 2026-02-26T23:51:58Z

~~blocked on/~~ part 2 of #969, wip towards closing #825

This PR implements parsing of block literals according to the language extension specification by Clang. Caveat: while the spec document specifies that the parameter list may only be omitted when the return type is omitted, Clang actually compiles programs that omit the return type but not the parameter list (excuse the linker error). The behavior here matches that behavior

Additionally, this change makes no attempt to track __block variable references within block bodies, since that's not necessary for the parse to complete, and that extra information would not be used anywhere yet. in the future, when implementing lowering support for blocks, this information tracking can be added

dotcarmen · 2026-02-28T15:56:53Z

i just realized aro doesn't support lowering to aarch64-macos - since macos is currently the only platform that works for testing blocks, i think this is enough to mark Blocks support as "completed" with the caveat that blocks don't get lowered, and an additional ticket should be opened for lowering literals and calls.

dotcarmen · 2026-06-14T02:12:02Z

        .weakref,
        .zero_call_used_regs,
        => |t| try p.err(tok, .attribute_todo, .{ @tagName(t), "functions" }),
+        // TODO: clang doesn't emit a dx here, but behavior for `__block <function>` is unspecified


i wonder if this might apply __block to the variable when initialized with this

eg for auto or id it could be eg id b = ^__block {}; instantiates b as a __block variable

looked into this by checking -dump-ast (no useful info besides "my hypothesis above is incorrect") and by glancing at the LLVM discourse a bit, couldn't find anything.

this is probably only a detail when lowering, the question is - should i remove this TODO? if clang truly doesn't do anything here, then i think an attribute ignored warning would be nice when not --emulate=clang. but if it does somehow affect compilation, then such a warning would be frivolous

dotcarmen · 2026-06-14T02:19:41Z

+        },
+
+        .sentinel,
+        .blocks, // TODO: clang doesn't emit any diagnostic, but it's not clear what this does


same as https://github.com/Vexu/arocc/pull/971/changes#r3408893811

Vexu · 2026-06-16T09:27:56Z

+    return .{
+        .node = node,
+        .qt = block_type,
+        .val = try .block(@intFromEnum(node), p.comp),


Does a block value need to exist? The only place where you handle it you explicitly ignore it.

technically it doesn't need to exist. i just created it

to satisfy the return type of fn primaryExpr

because it'd be needed when lowering

i can remove it and leave the value as undefined?

I don't see why you would need it when lowering since the same information is available from the node. You can just leave the value empty for non compile time known values.

Vexu · 2026-06-16T11:37:27Z

            }
        } else {
-            try some.coerce(p, ret_qt, e_tok, .ret);
+            block.return_type = if (ret_expr) |*some| some.qt else .void;


Missing lvalue conversion:

__auto_type a = ^(int a) { int arr[2]; return arr; };

Suggested change

block.return_type = if (ret_expr) |*some| some.qt else .void;

} else if (ret_expr) |*some| {

try some.lvalConversion(p, e_tok);

block.return_type = some.qt;

} else {

block.return_type = .void

clang warns about returning a pointer to a value on the stack. i couldn't find a similar diagnostic, so i'm assuming such detection is unimplemented.

dotcarmen

still have to finish handling the attributes that i handled before the attributes rework, and finish addressing previous review comments. attributes rework was nice - only had to fix 1 bug in an unused codepath.

the biggest change from the merge: i updated p.block to use a Node with a QualType, both of which get updated as more block literal information is parsed. this allows p.tree.attr_map.hasAttribute to work as expected.

dotcarmen · 2026-06-29T00:25:56Z

            return node.decl_ref_expr;
        }
-        if (@typeInfo(@TypeOf(Wanted)) == .@"enum" and Wanted.opts.enum_kind == .identifier and node == .identifier_arg) {
+        if (@typeInfo(Wanted) == .@"enum" and Wanted.opts.enum_kind == .identifier and node == .identifier_arg) {


bug fix for this previously-unused code path

dotcarmen · 2026-06-30T17:33:10Z

-block literals.c:23:17: error: __block attribute not allowed, only allowed on local variables
+block literals.c:23:17: warning: 'blocks' attribute only applies to local variables


some of the attribute diagnostics emitted by clang are errors, not warnings - but currently only warnings are emitted. i'm assuming this is fine?

You don't have to use checkTarget if you want to add a more specific diagnostic.

dotcarmen · 2026-07-01T23:08:41Z

+
+    const attr_state = p.wip_attrs.state(true);
+    defer p.wip_attrs.restore(attr_state);
+    try p.attributeSpecifier();


should keyword attributes be handled as part of attributeSpecifier?

As in __cdecl? Those are available via msTypeAttribute.

as in bare noinline, _Noreturn, etc - the keywords handled directly in fn declSpec

Those shouldn't be allowed here.

dotcarmen · 2026-07-02T14:48:01Z

btw i'm working on splitting out my merge commit to better show the updated blocks-related handling. i'll try to push it tonight

Vexu

Here's a diff to prevent a crash when using -fblocks without -fsyntax-only:

diff --git a/src/aro/CodeGen.zig b/src/aro/CodeGen.zig
index 082f41cf..4b322540 100644
--- a/src/aro/CodeGen.zig
+++ b/src/aro/CodeGen.zig
@@ -876,6 +876,7 @@ fn genExpr(c: *CodeGen, node_index: Node.Index) Error!Ir.Ref {
         .sizeof_expr,
         .builtin_va_arg_pack,
         .builtin_va_arg_pack_len,
+        .block_literal,
         => return c.fail("TODO CodeGen.genExpr {t}\n", .{node}),
         .codegen_diagnostic => |diagnostic| {
             try c.comp.diagnostics.addWithLocation(c.comp, .{

Vexu · 2026-07-04T10:28:45Z

        wip.current.attr = attr;
        wip.current.arg_i = 0;

+        if (is_block_literal and attr.syntax != .gnu) {


I preferred when you added this error in the parser.

Vexu · 2026-07-04T10:31:59Z

-block literals.c:23:17: error: __block attribute not allowed, only allowed on local variables
+block literals.c:23:17: warning: 'blocks' attribute only applies to local variables


You don't have to use checkTarget if you want to add a more specific diagnostic.

Vexu · 2026-07-04T10:33:24Z

+    return .{
+        .node = node,
+        .qt = block_type,
+        .val = try .block(@intFromEnum(node), p.comp),


I don't see why you would need it when lowering since the same information is available from the node. You can just leave the value empty for non compile time known values.

Vexu · 2026-07-04T10:52:44Z

+            if (ret_qt.isBlockLiteralAutoReturn()) {
+                func_ty.return_type = .void;
+                try block.qt.set(p.comp, .{ .func = func_ty });
+            } else if (last_noreturn != .yes) {


Missing isInvalid() check.

Vexu · 2026-07-04T10:53:43Z

+    if (try p.typeName()) |typename| {
+        if (typename.is(p.comp, .func)) {
+            qt = typename;
+        } else {


Needs a check for array types:

^int [2] {};

Vexu · 2026-07-04T10:56:47Z

+
+    var compound_stmt_state: StmtExprState = .{};
+    const body = try p.compoundStmt(true, &compound_stmt_state) orelse {
+        try p.err(p.tok_i, .missing_block_literal_body, .{});


This should not be fatal, the note is never added because of it.

dotcarmen force-pushed the dotcarmen/block-literals branch 2 times, most recently from f0b3a01 to 4a15846 Compare February 27, 2026 01:06

dotcarmen marked this pull request as ready for review February 27, 2026 01:27

This comment was marked as resolved.

Sign in to view

This comment was marked as outdated.

Sign in to view

dotcarmen marked this pull request as draft February 27, 2026 02:14

dotcarmen force-pushed the dotcarmen/block-literals branch 10 times, most recently from a82f534 to 51c20b7 Compare February 28, 2026 15:54

dotcarmen marked this pull request as ready for review February 28, 2026 15:54

dotcarmen mentioned this pull request Feb 28, 2026

objective-c support #970

Open

12 tasks

dotcarmen force-pushed the dotcarmen/block-literals branch 2 times, most recently from 22a3bdb to 201fca6 Compare March 4, 2026 14:42

Vexu mentioned this pull request Mar 13, 2026

Rename 'TypeStore' to 'TypeMap' #967

Open

dotcarmen force-pushed the dotcarmen/block-literals branch from 201fca6 to a66ae0c Compare March 18, 2026 00:55

dotcarmen force-pushed the dotcarmen/block-literals branch 2 times, most recently from a295122 to 4f224ce Compare March 25, 2026 22:08

This comment was marked as outdated.

Sign in to view

dotcarmen force-pushed the dotcarmen/block-literals branch 4 times, most recently from 73b3cad to c9e93a3 Compare March 28, 2026 12:33

dotcarmen force-pushed the dotcarmen/block-literals branch 6 times, most recently from 2e2bc28 to fad7906 Compare June 14, 2026 02:19

dotcarmen commented Jun 14, 2026

View reviewed changes

dotcarmen force-pushed the dotcarmen/block-literals branch from fad7906 to 5cbbdea Compare June 15, 2026 01:08

dotcarmen requested a review from Vexu June 15, 2026 01:13

Vexu reviewed Jun 16, 2026

View reviewed changes

dotcarmen force-pushed the dotcarmen/block-literals branch from 5cbbdea to 7cf3ccd Compare June 16, 2026 23:42

vancluever mentioned this pull request Jun 18, 2026

Issue parsing MacOS CoreGraphics #1052

Closed

feat: parser-level support for block literals and __block variables

8564289

dotcarmen force-pushed the dotcarmen/block-literals branch from 7cf3ccd to f05a42a Compare June 23, 2026 19:21

use __attribute__((blocks(byref))) instead of __block storage class

33553d3

dotcarmen force-pushed the dotcarmen/block-literals branch from f05a42a to d985071 Compare June 29, 2026 00:11

dotcarmen commented Jun 29, 2026

View reviewed changes

dotcarmen force-pushed the dotcarmen/block-literals branch from d985071 to e2cfd6d Compare June 30, 2026 17:32

dotcarmen commented Jun 30, 2026

View reviewed changes

dotcarmen force-pushed the dotcarmen/block-literals branch from e2cfd6d to 7e599a7 Compare June 30, 2026 18:20

dotcarmen requested a review from Vexu June 30, 2026 18:20

dotcarmen commented Jul 1, 2026

View reviewed changes

merge master

8f865a5

dotcarmen added 2 commits July 2, 2026 22:21

attributes using rework

9456d98

add missing lval conversion

c8af2f8

dotcarmen force-pushed the dotcarmen/block-literals branch from 7e599a7 to c8af2f8 Compare July 2, 2026 20:23

Vexu reviewed Jul 4, 2026

View reviewed changes

Vexu mentioned this pull request Jul 7, 2026

Compilation: define __BLOCKS__ when blocks are enabled #1074

Open

-            block.return_type = if (ret_expr) |*some| some.qt else .void;
+        } else if (ret_expr) |*some| {
+            try some.lvalConversion(p, e_tok);
+            block.return_type = some.qt;
+        } else {
+            block.return_type = .void

		block literals.c:23:17: error: __block attribute not allowed, only allowed on local variables
		block literals.c:23:17: warning: 'blocks' attribute only applies to local variables

Conversation

dotcarmen commented Feb 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as resolved.

This comment was marked as outdated.

dotcarmen commented Feb 28, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

This comment was marked as outdated.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dotcarmen left a comment • 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!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

dotcarmen commented Jul 2, 2026

Uh oh!

Vexu left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

dotcarmen commented Feb 26, 2026 •

edited

Loading

dotcarmen commented Feb 28, 2026 •

edited

Loading

dotcarmen left a comment •

edited

Loading