maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Parser/cxx1z-init-statement.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

52 lines
1.6 KiB
C++
Raw Normal View History

P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
// RUN: %clang_cc1 -std=c++1z -verify %s -Wno-vexing-parse
int g, h;
typedef int T;
int f() {
// init-statement declarations
P0305R0: Semantic analysis and code generation for C++17 init-statement for 'if' and 'switch': if (stmt; condition) { ... } Patch by Anton Bikineev! Some minor formatting and comment tweets by me. llvm-svn: 275350
2016-07-14 08:11:03 +08:00
if (T n = 0; n != 0) {}
if (T f(); f()) {}
if (T(f()); f()) {}
if (T(f()), g, h; f()) {}
if (T f(); f()) {}
if (T f(), g, h; f()) {}
if (T(n) = 0; n) {}
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
// init-statement expressions
Refactor the way we handle diagnosing unused expression results. Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement. This patch fixes PR39837. llvm-svn: 350404
2019-01-05 00:58:14 +08:00
if (T{f()}; f()) {} // expected-warning {{expression result unused}}
if (T{f()}, g, h; f()) {} // expected-warning 2{{unused}} expected-warning {{expression result unused}}
if (T(f()), g, h + 1; f()) {} // expected-warning 2{{unused}} expected-warning {{expression result unused}}
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
// condition declarations
if (T(n){g}) {}
if (T f()) {} // expected-error {{function type}}
if (T f(), g, h) {} // expected-error {{function type}}
Fix typo-correction crash if a typo occurs within the operand of a function-style cast to a non-dependent type which is then used in an invalid way. We'd lose the "type dependent" bit here, and downstream Sema processing would then discard the expression if it was used in a context where its type rendered it invalid. llvm-svn: 274267
2016-07-01 04:24:30 +08:00
if (T(n) = 0) {}
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
// condition expressions
if (T(f())) {}
if (T{f()}) {}
if (T(f()), g, h) {} // expected-warning 2{{unused}}
if (T{f()}, g, h) {} // expected-warning 2{{unused}}
Fix typo-correction crash if a typo occurs within the operand of a function-style cast to a non-dependent type which is then used in an invalid way. We'd lose the "type dependent" bit here, and downstream Sema processing would then discard the expression if it was used in a context where its type rendered it invalid. llvm-svn: 274267
2016-07-01 04:24:30 +08:00
// none of the above, disambiguated as expression (can't be a declaration)
if (T(n)(g)) {} // expected-error {{undeclared identifier 'n'}}
if (T(n)(int())) {} // expected-error {{undeclared identifier 'n'}}
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
// Likewise for 'switch'
P0305R0: Semantic analysis and code generation for C++17 init-statement for 'if' and 'switch': if (stmt; condition) { ... } Patch by Anton Bikineev! Some minor formatting and comment tweets by me. llvm-svn: 275350
2016-07-14 08:11:03 +08:00
switch (int n; n) {}
Refactor the way we handle diagnosing unused expression results. Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement. This patch fixes PR39837. llvm-svn: 350404
2019-01-05 00:58:14 +08:00
switch (g; int g = 5) {} // expected-warning {{expression result unused}}
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
P0305R0: Semantic analysis and code generation for C++17 init-statement for 'if' and 'switch': if (stmt; condition) { ... } Patch by Anton Bikineev! Some minor formatting and comment tweets by me. llvm-svn: 275350
2016-07-14 08:11:03 +08:00
if (int a, b; int c = a) { // expected-note 6{{previous}}
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
int a; // expected-error {{redefinition}}
int b; // expected-error {{redefinition}}
int c; // expected-error {{redefinition}}
} else {
int a; // expected-error {{redefinition}}
int b; // expected-error {{redefinition}}
int c; // expected-error {{redefinition}}
}
P0305R0: Semantic analysis and code generation for C++17 init-statement for 'if' and 'switch': if (stmt; condition) { ... } Patch by Anton Bikineev! Some minor formatting and comment tweets by me. llvm-svn: 275350
2016-07-14 08:11:03 +08:00
return 0;
P0305R1: Parsing support for init-statements in 'if' and 'switch' statements. No semantic analysis yet. This is a pain to disambiguate correctly, because the parsing rules for the declaration form of a condition and of an init-statement are quite different -- for a token sequence that looks like a declaration, we frequently need to disambiguate all the way to the ')' or ';'. We could do better here in some cases by stopping disambiguation once we've decided whether we've got an expression or not (rather than keeping going until we know whether it's an init-statement declaration or a condition declaration), by unifying our parsing code for the two types of declaration and moving the syntactic checks into Sema; if this has a measurable impact on parsing performance, I'll look into that. llvm-svn: 274169
2016-06-30 05:17:59 +08:00
}