llvm-project/clang/test/SemaCXX/comma.cpp

// RUN: %clang_cc1 -fsyntax-only -verify %s
// expected-no-diagnostics

// PR6076
void f();
void (&g)() = (void(), f);

int a[1];
int (&b)[1] = (void(), a);
Implement the lvalue-to-rvalue conversion where needed. The lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class type to rvalue expressions of the unqualified variant of that type. For example, given: const int i; (void)(i + 17); the lvalue-to-rvalue conversion for the subexpression "i" will turn it from an lvalue expression (a DeclRefExpr) with type 'const int' into an rvalue expression with type 'int'. Both C and C++ mandate this conversion, and somehow we've slid through without implementing it. We now have both DefaultFunctionArrayConversion and DefaultFunctionArrayLvalueConversion, and which gets used depends on whether we do the lvalue-to-rvalue conversion or not. Generally, we do the lvalue-to-rvalue conversion, but there are a few notable exceptions: - the left-hand side of a '.' operator - the left-hand side of an assignment - a C++ throw expression - a subscript expression that's subscripting a vector Making this change exposed two issues with blocks: - we were deducing const-qualified return types of non-class type from a block return, which doesn't fit well - we weren't always setting the known return type of a block when it was provided with the ^return-type syntax Fixes the current Clang-on-Clang compile failure and PR6076. llvm-svn: 95167 2010-02-03 08:27:59 +08:00			`// RUN: %clang_cc1 -fsyntax-only -verify %s`
Prior to adding the new "expected-no-diagnostics" directive to VerifyDiagnosticConsumer, make the necessary adjustment to 580 test-cases which will henceforth require this new directive. llvm-svn: 166280 2012-10-19 20:44:48 +08:00			`// expected-no-diagnostics`
Implement the lvalue-to-rvalue conversion where needed. The lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class type to rvalue expressions of the unqualified variant of that type. For example, given: const int i; (void)(i + 17); the lvalue-to-rvalue conversion for the subexpression "i" will turn it from an lvalue expression (a DeclRefExpr) with type 'const int' into an rvalue expression with type 'int'. Both C and C++ mandate this conversion, and somehow we've slid through without implementing it. We now have both DefaultFunctionArrayConversion and DefaultFunctionArrayLvalueConversion, and which gets used depends on whether we do the lvalue-to-rvalue conversion or not. Generally, we do the lvalue-to-rvalue conversion, but there are a few notable exceptions: - the left-hand side of a '.' operator - the left-hand side of an assignment - a C++ throw expression - a subscript expression that's subscripting a vector Making this change exposed two issues with blocks: - we were deducing const-qualified return types of non-class type from a block return, which doesn't fit well - we weren't always setting the known return type of a block when it was provided with the ^return-type syntax Fixes the current Clang-on-Clang compile failure and PR6076. llvm-svn: 95167 2010-02-03 08:27:59 +08:00
			`// PR6076`
			`void f();`
			`void (&g)() = (void(), f);`

			`int a[1];`
			`int (&b)[1] = (void(), a);`