@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
languagelawyer
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
languagelawyer
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
cor3ntin wrote
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
AaronBallman w
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
AaronBallman w
languagelawyer wrote:
> it is CWG2548; that's what made it clear that array-to-pointer decay does not
> happen here
CWG2548 is closed as NAD, with no changes to the wording. The fact that
array-to-pointer decay does not happen has always been clear
> despite that being inconsistent with the r
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
AaronBallman w
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
languagelawyer
https://github.com/languagelawyer edited
https://github.com/llvm/llvm-project/pull/140702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
AaronBallman wrote:
> > it is CWG2548; that's what made it clear that array-to-pointer decay does
> > not happen here
>
> CWG2548 is closed as NAD, with no changes to the wording.
Correct.
> The fact that array-to-pointer decay does not happen has always been clear
Incorrect; the reason the
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
languagelawyer
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
Sirraide wrote
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
AaronBallman w
AaronBallman wrote:
> > This is related to CWG2548
>
> Kinda, but not really. It has never been necessary to create that
> (non-)issue. Or does someone really believe that it is a C++ defect that `IA{
> 1, 2, 3 } - IA{ 1, 2, 3 }` is not allowed? So, it is just a bug since C++11
I think it is
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
zwuis wrote:
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
languagelawyer
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
zwuis wrote:
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
Sirraide wrote
https://github.com/languagelawyer edited
https://github.com/llvm/llvm-project/pull/140702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
languagelawyer
@@ -15840,6 +15859,11 @@ ExprResult Sema::CreateBuiltinUnaryOp(SourceLocation
OpLoc,
InputExpr->getType()->isSpecificBuiltinType(BuiltinType::Dependent)) {
resultType = Context.DependentTy;
} else {
+if (Opc == UO_Deref || Opc == UO_Plus) {
Sir
@@ -7639,6 +7639,8 @@ def warn_param_mismatched_alignment : Warning<
def err_objc_object_assignment : Error<
"cannot assign to class object (%0 invalid)">;
+def err_typecheck_array_prvalue_operand : Error<
+ "array prvalue is not permitted">;
Sirraide wrote
@@ -16,4 +15,13 @@ int main()
f0(a1);
f1(a2);
f2(a3);
+
+ using IA = int[];
+ void(+IA{ 1, 2, 3 }); // expected-error {{array prvalue}}
Sirraide wrote:
Can you add some tests here to make sure that we don’t complain about array
glvalues?
https://gith
languagelawyer wrote:
@pinskia the thing is, GCC started accepting ill-formed code right when it was
reaffirmed it is ill-formed
https://github.com/llvm/llvm-project/pull/140702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llv
AaronBallman wrote:
> > That probably should continue to work -- we accept it today and so does GCC
>
> GCC started accepting it from version 14, likely when fixing
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94264 (it is mentioned in
> [#54016
> (comment)](https://github.com/llvm/llvm-pro
languagelawyer wrote:
> That probably should continue to work -- we accept it today and so does GCC
GCC started accepting it from version 14, likely when fixing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94264 (it is mentioned in
https://github.com/llvm/llvm-project/issues/54016#issuecomment
AaronBallman wrote:
> However, it "breaks" compound literal C++ extension:
>
> ```
> $ build/bin/clang++ -fsyntax-only test.cxx
> test.cxx:12:2: error: array prvalue is not permitted
>12 | *((int []){ 1, 2, 3});
> | ^
> test.cxx:13:23: error: array
AaronBallman wrote:
> > Is this going to break behavior in C?
>
> Array **prvalues** is C++11+ exclusive thing. Compound literals are lvalues
> in C
Ah, good point, I wasn't remembering that C and C++ are different in how they
handle compound literals. And you can return a pointer to an arra
languagelawyer wrote:
> Is this going to break behavior in C?
Array **prvalues** is C++11+ exclusive thing. Compound literals are lvalues in
C https://port70.net/~nsz/c/c11/n1570.html#6.5.2.5p4
Anyway, here is a check:
```sh
$ build/bin/clang -fsyntax-only test.c
test.c:2:3: warning: expression
https://github.com/AaronBallman commented:
Is this going to break behavior in C? https://godbolt.org/z/PsPPs8ov1
https://github.com/llvm/llvm-project/pull/140702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mai
https://github.com/languagelawyer updated
https://github.com/llvm/llvm-project/pull/140702
>From f6067249c40ad8423048b718be53e69f74b8607d Mon Sep 17 00:00:00 2001
From: Andrey Erokhin
Date: Tue, 20 May 2025 14:58:23 +0500
Subject: [PATCH] [Clang][Sema] Reject array prvalue operands
of unary +
https://github.com/languagelawyer updated
https://github.com/llvm/llvm-project/pull/140702
>From df91056b5ccbb0f51945f21cd5b2e5bca31eee7f Mon Sep 17 00:00:00 2001
From: Andrey Erokhin
Date: Tue, 20 May 2025 14:58:23 +0500
Subject: [PATCH] [Clang][Sema] Reject array prvalue operands
of unary +
zwuis wrote:
This is related to CWG2548. CC @Endilll
https://github.com/llvm/llvm-project/pull/140702
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
languagelawyer wrote:
> This is related to CWG2548
Kinda, but not really. It has never been necessary to create the (non-)issue.
Or does someone really believe that it is a C++ defect that `IA{ 1, 2, 3 } -
IA{ 1, 2, 3 }` is not allowed?
https://github.com/llvm/llvm-project/pull/140702
___
github-actions[bot] wrote:
:warning: C/C++ code formatter, clang-format found issues in your code.
:warning:
You can test this locally with the following command:
``bash
git-clang-format --diff HEAD~1 HEAD --extensions cpp --
clang/lib/Sema/SemaExpr.cpp clang/test/CXX/expr/p8.cp
llvmbot wrote:
@llvm/pr-subscribers-clang
Author: None (languagelawyer)
Changes
of unary `+` and `*`, and binary `+` and `-` operators
Fixes #54016
---
Full diff: https://github.com/llvm/llvm-project/pull/140702.diff
2 Files Affected:
- (modified) clang/lib/Sema/SemaExpr.cpp (+21)
-
github-actions[bot] wrote:
Thank you for submitting a Pull Request (PR) to the LLVM Project!
This PR will be automatically labeled and the relevant teams will be notified.
If you wish to, you can add reviewers by using the "Reviewers" section on this
page.
If this is not working for you, it
https://github.com/languagelawyer created
https://github.com/llvm/llvm-project/pull/140702
of unary `+` and `*`, and binary `+` and `-` operators
Fixes #54016
>From 2914130e2273eb279b978b73f58d5a2d257decb4 Mon Sep 17 00:00:00 2001
From: Andrey Erokhin
Date: Tue, 20 May 2025 14:58:23 +0500
Sub
38 matches
Mail list logo
