[clang] Statement expressions with trailing semicolons behave differently from GCC

[KaiYG]

int foo() {
    return ({1; 2; 3;;});
}

https://godbolt.org/z/W5PYc1PE4

In G++, the statement expression results in a null, while in Clang++ it evaluates to 3.

This difference is likely caused by b1e511b, but I’m not sure what the intended behavior is supposed to be.

[frederick-vs-ja]

The commit message said

Ignore trailing NullStmts in compound expressions when determining the result type and value. This is to match the GCC behavior which ignores semicolons at the end of compound expressions.

... which didn't seem correct.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: KaiWeng (KaiYG)

``` int foo() { return ({1; 2; 3;;}); } ``` [https://godbolt.org/z/W5PYc1PE4](https://godbolt.org/z/W5PYc1PE4)

In GCC, the statement expression results in a null, while in Clang it evaluates to 3.

This difference is likely caused by b1e511b, but I’m not sure what the intended behavior is supposed to be.

[zygoloid]

In GCC, trailing ;s are ignored in C only. We probably don't want to do the same in Clang; that just looks like a bug in either GCC's C or C++ frontend. We should ask them which one.

[shafik]

CC @pinskia @AaronBallman

[pinskia]

Looks like what is happening for the GCC's C front-end is an empty statement that is ; by itself does NOT add to the statement lists so it is ignored. This is the behavior since at least GCC 4.0. (I don't have any earlier to test). and then when finished with the statement expression, the front-end only looks at the statement list.

While the GCC's C++ front-end does the processing/parsing of a statement expression differently. the end of the statement expression is handled while parsing of the last expression.

Now the documentation of statement expressions (https://gcc.gnu.org/onlinedocs/gcc-15.2.0/gcc/Statement-Exprs.html) imply the C++ behavior though:

The last thing in the compound statement should be an expression followed by a semicolon; the value of this subexpression serves as the value of the entire construct. (If you use some other kind of statement last within the braces, the construct has type void, and thus effectively no value.)

Filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122050 asking which is the correct behavior.
And the general consensus is the GCC's C front-end is WRONG and the type here should be void. Also the behavior of the GCC's C front-end is dating back to GCC 2.7.2.3 (1997) at least.

[AaronBallman]

I think this might qualify as a good first issue; Clang's original behavior was correct, so this should be a matter of backing out b1e511b.

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Check that no other contributor is working on this issue. If someone is assigned to the issue or claimed to be working on it, ping the person. After one week without a response, the assignee may be changed.
2. Leave a comment indicating that you are working on the issue, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
3. Fix the issue locally.
4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
5. Create a Git commit.
6. Run git clang-format HEAD~1 to format your changes.
7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

Author: KaiWeng (KaiYG)

``` int foo() { return ({1; 2; 3;;}); } ``` [https://godbolt.org/z/W5PYc1PE4](https://godbolt.org/z/W5PYc1PE4)

In G++, the statement expression results in a null, while in Clang++ it evaluates to 3.

This difference is likely caused by b1e511b, but I’m not sure what the intended behavior is supposed to be.

[KaiYG]

I would like to work on it.