We need to evaluated the RHS before the LHS.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/AST/Interp/ByteCodeExprGen.cpp | ||
---|---|---|
623–625 | In C, the evaluation of the operands are unsequenced. C doesn't currently have constexpr functions, only constexpr objects, but that eliminates mutating operations like compound assignment... for the moment. Perhaps a FIXME comment for figuring out how to handle C? (The situation I'm worried about in C is with UB dealing with unsequenced operations, like rejecting: https://godbolt.org/z/W11jchrKc) |
clang/lib/AST/Interp/ByteCodeExprGen.cpp | ||
---|---|---|
623–625 | Could C make them sequenced when introducing constexpr functions? :) |
clang/lib/AST/Interp/ByteCodeExprGen.cpp | ||
---|---|---|
623–625 | Since we already emit a warning for this, we could in the future just check if the statement is in a constexpr function and emit an error instead? We're emitting the warning for c++ pre-17 as well but we don't make it an error, I guess because it's not UB there? |
clang/lib/AST/Interp/ByteCodeExprGen.cpp | ||
---|---|---|
623–625 | If we're actually leaving the operations unsequenced before C++17, then we should reject that code because it is UB: http://eel.is/c++draft/basic#intro.execution-10 The wording in C++14 for assignment operations is:
So the left and right operands are unsequenced relative to one another. |
clang/lib/AST/Interp/ByteCodeExprGen.cpp | ||
---|---|---|
623–625 | I was looking at the existing implementation when writing this patch: https://github.com/llvm/llvm-project/blob/1a7a00bdc99fa2b2ca19ecd2d1069991b3c1006b/clang/lib/AST/ExprConstant.cpp#L8545-L8568 which always seems to evaluate RHS first (and actually abort for C++ <= 14, but for unrelated reasons, probably because this statement is just not supported in a constexpr context there). |
clang/lib/AST/Interp/ByteCodeExprGen.cpp | ||
---|---|---|
623–625 | I think the existing implementation is incorrect to accept this in C++14 and earlier: https://eel.is/c++draft/basic.exec#intro.execution-10.sentence-4 |
clang/lib/AST/Interp/ByteCodeExprGen.cpp | ||
---|---|---|
623–625 | I filed a bug on this a while ago that we don't catch unsequenced modifications in constant expressions contexts: https://github.com/llvm/llvm-project/issues/37768 I am almost sure I had a conversation with @rsmith about this. |
LGTM with an extra comment added.
clang/lib/AST/Interp/ByteCodeExprGen.cpp | ||
---|---|---|
623–625 | Let's add the FIXME comment here as well and come back to address the issue with sequencing later. |
In C, the evaluation of the operands are unsequenced. C doesn't currently have constexpr functions, only constexpr objects, but that eliminates mutating operations like compound assignment... for the moment. Perhaps a FIXME comment for figuring out how to handle C?
(The situation I'm worried about in C is with UB dealing with unsequenced operations, like rejecting: https://godbolt.org/z/W11jchrKc)