================ @@ -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 wrote:
>> if you're coming from a C background > What about Python/Java background? They're not particularly relevant because you don't directly mix Java and C++ code in the same way you do with C and C++ as happens in header files. >> IIRC there's no rvalue conversion on the statement expression result so I >> think that ends up being a prvalue of array type > This is not correct, statement expressions (their "result") undergo array and > function pointer decay (independently of the context where they appear), so > you're getting a "dangling pointer" I was incorrectly remembering the behavior from returning a `char` and not having it promote to an `int`. I can confirm we decay the array: https://godbolt.org/z/zhW1fnsej but you can hit the same concern I had via a `typedef` or `using`, where the type information is actually slightly helpful in understanding the issue: `using foo = int[10]; foo{} + 0;` (keeping in mind that `foo{}` could also be behind a macro where it's not easy for the user to spot the `{}` and realize there's a temporary involved). So I still find a formulation that includes the type information a bit more user-friendly, but that could be included in a new diagnostic that talks about temporary arrays. 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
