maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Analysis/cfg.cpp

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

619 lines
18 KiB
C++
Raw Normal View History

[AST, analyzer] Transform rvalue cast outputs to lvalues (fheinous-gnu-extensions) Despite the fact that cast expressions return rvalues, GCC still handles such outputs as lvalues when compiling inline assembler. In this commit, we are treating it by removing LValueToRValue casts inside GCCAsmStmt outputs. Differential Revision: https://reviews.llvm.org/D45416 llvm-svn: 344864
2018-10-21 06:49:23 +08:00
// RUN: %clang_analyze_cc1 -analyzer-checker=debug.DumpCFG -triple x86_64-apple-darwin12 -fheinous-gnu-extensions -std=c++11 -analyzer-config cfg-rich-constructors=false %s > %t 2>&1
[CFG] Add extra context to C++ constructor statement elements. This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional information to provide regarding what sort of object is being constructed. It is useful for figuring out what memory is initialized in client of the CFG such as the Static Analyzer, which do not operate by recursive AST traversal, but instead rely on the CFG to provide all the information when they need it. Otherwise, the statement that triggers the construction and defines what memory is being initialized would normally occur after the construct-expression, and the client would need to peek to the next CFG element or use statement parent map to understand the necessary facts about the construct-expression. As a proof of concept, CFGConstructors are added for new-expressions and the respective test cases are provided to demonstrate how it works. For now, the only additional data contained in the CFGConstructor element is the "trigger statement", such as new-expression, which is the parent of the constructor. It will be significantly expanded in later commits. The additional data is organized as an auxiliary structure - the "construction context", which is allocated separately from the CFGElement. Differential Revision: https://reviews.llvm.org/D42672 llvm-svn: 324668
2018-02-09 06:58:15 +08:00
// RUN: FileCheck --input-file=%t -check-prefixes=CHECK,WARNINGS %s
[AST, analyzer] Transform rvalue cast outputs to lvalues (fheinous-gnu-extensions) Despite the fact that cast expressions return rvalues, GCC still handles such outputs as lvalues when compiling inline assembler. In this commit, we are treating it by removing LValueToRValue casts inside GCCAsmStmt outputs. Differential Revision: https://reviews.llvm.org/D45416 llvm-svn: 344864
2018-10-21 06:49:23 +08:00
// RUN: %clang_analyze_cc1 -analyzer-checker=debug.DumpCFG -triple x86_64-apple-darwin12 -fheinous-gnu-extensions -std=c++11 -analyzer-config cfg-rich-constructors=true %s > %t 2>&1
[CFG] Add extra context to C++ constructor statement elements. This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional information to provide regarding what sort of object is being constructed. It is useful for figuring out what memory is initialized in client of the CFG such as the Static Analyzer, which do not operate by recursive AST traversal, but instead rely on the CFG to provide all the information when they need it. Otherwise, the statement that triggers the construction and defines what memory is being initialized would normally occur after the construct-expression, and the client would need to peek to the next CFG element or use statement parent map to understand the necessary facts about the construct-expression. As a proof of concept, CFGConstructors are added for new-expressions and the respective test cases are provided to demonstrate how it works. For now, the only additional data contained in the CFGConstructor element is the "trigger statement", such as new-expression, which is the parent of the constructor. It will be significantly expanded in later commits. The additional data is organized as an auxiliary structure - the "construction context", which is allocated separately from the CFGElement. Differential Revision: https://reviews.llvm.org/D42672 llvm-svn: 324668
2018-02-09 06:58:15 +08:00
// RUN: FileCheck --input-file=%t -check-prefixes=CHECK,ANALYZER %s
// This file tests how we construct two different flavors of the Clang CFG -
// the CFG used by the Sema analysis-based warnings and the CFG used by the
// static analyzer. The difference in the behavior is checked via FileCheck
// prefixes (WARNINGS and ANALYZER respectively). When introducing new analyzer
// flags, no new run lines should be added - just these flags would go to the
// respective line depending on where is it turned on and where is it turned
// off. Feel free to add tests that test only one of the CFG flavors if you're
// not sure how the other flavor is supposed to work in your case.
CFG.cpp: Fix wrapping logic when printing block preds/succs. First check only wrapped with i==8, second wrapped at i==2,8,18,28,... This fix restores the intended behavior: i==8,18,28,... Found with -fsanitize=integer. llvm-svn: 171718
2013-01-07 17:51:17 +08:00
[analyzer] Print function name when dumping its CFG. This allows us to use CHECK-LABEL to ensure that we're checking the right CFG. Debugging change only. llvm-svn: 199320
2014-01-16 01:25:05 +08:00
// CHECK-LABEL: void checkDeclStmts()
CFG: In a DeclStmt, skip anything that's not a VarDecl. Neither the compiler nor the analyzer are doing anything with non-VarDecl decls in the CFG, and having them there creates extra nodes in the analyzer's path diagnostics. Simplify the CFG (and the path edges) by simply leaving them out. We can always add interesting decls back in when they become relevant. Note that this only affects decls declared in a DeclStmt, and then only those that appear within a function body. llvm-svn: 183157
2013-06-04 06:59:41 +08:00
// CHECK: ENTRY
// CHECK-NEXT: Succs (1): B1
// CHECK: [B1]
// CHECK-NEXT: 1: int i;
// CHECK-NEXT: 2: int j;
// CHECK-NEXT: 3: 1
// CHECK-NEXT: 4: int k = 1;
// CHECK-NEXT: 5: int l;
// CHECK-NEXT: 6: 2
// CHECK-NEXT: 7: int m = 2;
[CFG] Add construction context for simple variable declarations. Constructors of simple variables now can be queried to discover that they're constructing into simple variables. Differential Revision: https://reviews.llvm.org/D42699 llvm-svn: 324794
2018-02-10 09:55:23 +08:00
// WARNINGS-NEXT: (CXXConstructExpr, struct standalone)
// ANALYZER-NEXT: (CXXConstructExpr, [B1.9], struct standalone)
CFG: In a DeclStmt, skip anything that's not a VarDecl. Neither the compiler nor the analyzer are doing anything with non-VarDecl decls in the CFG, and having them there creates extra nodes in the analyzer's path diagnostics. Simplify the CFG (and the path edges) by simply leaving them out. We can always add interesting decls back in when they become relevant. Note that this only affects decls declared in a DeclStmt, and then only those that appear within a function body. llvm-svn: 183157
2013-06-04 06:59:41 +08:00
// CHECK-NEXT: 9: struct standalone myStandalone;
Modify TypePrinter to differentiate between anonymous struct and unnamed struct Currently TypePrinter lumps anonymous classes and unnamed classes in one group "anonymous" this is not correct and can be confusing in some contexts. Differential Revision: https://reviews.llvm.org/D96807
2021-02-23 01:58:26 +08:00
// WARNINGS-NEXT: (CXXConstructExpr, struct (unnamed struct at {{.*}}))
// ANALYZER-NEXT: (CXXConstructExpr, [B1.11], struct (unnamed struct at {{.*}}))
// CHECK-NEXT: 11: struct (unnamed struct at {{.*}}) myAnon;
[CFG] Add construction context for simple variable declarations. Constructors of simple variables now can be queried to discover that they're constructing into simple variables. Differential Revision: https://reviews.llvm.org/D42699 llvm-svn: 324794
2018-02-10 09:55:23 +08:00
// WARNINGS-NEXT: (CXXConstructExpr, struct named)
// ANALYZER-NEXT: (CXXConstructExpr, [B1.13], struct named)
CFG: In a DeclStmt, skip anything that's not a VarDecl. Neither the compiler nor the analyzer are doing anything with non-VarDecl decls in the CFG, and having them there creates extra nodes in the analyzer's path diagnostics. Simplify the CFG (and the path edges) by simply leaving them out. We can always add interesting decls back in when they become relevant. Note that this only affects decls declared in a DeclStmt, and then only those that appear within a function body. llvm-svn: 183157
2013-06-04 06:59:41 +08:00
// CHECK-NEXT: 13: struct named myNamed;
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B0
void checkDeclStmts() {
int i, j;
int k = 1, l, m = 2;
struct standalone { int x, y; };
struct standalone myStandalone;
struct { int x, y; } myAnon;
struct named { int x, y; } myNamed;
static_assert(1, "abc");
}
Analysis: Add a CFG successor to a SwitchStmt if it is both empty and fully covered Consider the case where a SwitchStmt satisfied isAllEnumCasesCovered() as well as having no cases at all (i.e. the enum it covers has no enumerators). In this case, we should add a successor to repair the CFG. This fixes PR16212. llvm-svn: 183237
2013-06-05 01:38:44 +08:00
[analyzer] Print function name when dumping its CFG. This allows us to use CHECK-LABEL to ensure that we're checking the right CFG. Debugging change only. llvm-svn: 199320
2014-01-16 01:25:05 +08:00
// CHECK-LABEL: void F(EmptyE e)
Analysis: Add a CFG successor to a SwitchStmt if it is both empty and fully covered Consider the case where a SwitchStmt satisfied isAllEnumCasesCovered() as well as having no cases at all (i.e. the enum it covers has no enumerators). In this case, we should add a successor to repair the CFG. This fixes PR16212. llvm-svn: 183237
2013-06-05 01:38:44 +08:00
// CHECK: ENTRY
// CHECK-NEXT: Succs (1): B1
// CHECK: [B1]
// CHECK-NEXT: 1: e
// CHECK-NEXT: 2: [B1.1] (ImplicitCastExpr, LValueToRValue, enum EmptyE)
// CHECK-NEXT: 3: [B1.2] (ImplicitCastExpr, IntegralCast, int)
// CHECK-NEXT: T: switch [B1.3]
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B0
// CHECK: [B0 (EXIT)]
// CHECK-NEXT: Preds (1): B1
enum EmptyE {};
void F(EmptyE e) {
switch (e) {}
}
Omit arguments of __builtin_object_size from the CFG. This builtin does not actually evaluate its arguments for side effects, so we shouldn't include them in the CFG. In the analyzer, rely on the constant expression evaluator to get the proper semantics, at least for now. (In the future, we could get ambitious and try to provide path- sensitive size values.) In theory, this does pose a problem for liveness analysis: a variable can be used within the __builtin_object_size argument expression but not show up as live. However, it is very unlikely that such a value would be used to compute the object size and not used to access the object in some way. <rdar://problem/14760817> llvm-svn: 188679
2013-08-20 00:27:28 +08:00
[analyzer] Print function name when dumping its CFG. This allows us to use CHECK-LABEL to ensure that we're checking the right CFG. Debugging change only. llvm-svn: 199320
2014-01-16 01:25:05 +08:00
// CHECK-LABEL: void testBuiltinSize()
Omit arguments of __builtin_object_size from the CFG. This builtin does not actually evaluate its arguments for side effects, so we shouldn't include them in the CFG. In the analyzer, rely on the constant expression evaluator to get the proper semantics, at least for now. (In the future, we could get ambitious and try to provide path- sensitive size values.) In theory, this does pose a problem for liveness analysis: a variable can be used within the __builtin_object_size argument expression but not show up as live. However, it is very unlikely that such a value would be used to compute the object size and not used to access the object in some way. <rdar://problem/14760817> llvm-svn: 188679
2013-08-20 00:27:28 +08:00
// CHECK: ENTRY
// CHECK-NEXT: Succs (1): B1
// CHECK: [B1]
// CHECK-NEXT: 1: __builtin_object_size
[c++1z] Include "noexcept" in builtin function types where appropriate. Fixes an assertion failure looking up a matching ::operator delete for __builtin_operator_delete. llvm-svn: 284458
2016-10-18 15:13:55 +08:00
// CHECK-NEXT: 2: [B1.1] (ImplicitCastExpr, BuiltinFnToFnPtr, unsigned long (*)(const void *, int) noexcept)
Omit arguments of __builtin_object_size from the CFG. This builtin does not actually evaluate its arguments for side effects, so we shouldn't include them in the CFG. In the analyzer, rely on the constant expression evaluator to get the proper semantics, at least for now. (In the future, we could get ambitious and try to provide path- sensitive size values.) In theory, this does pose a problem for liveness analysis: a variable can be used within the __builtin_object_size argument expression but not show up as live. However, it is very unlikely that such a value would be used to compute the object size and not used to access the object in some way. <rdar://problem/14760817> llvm-svn: 188679
2013-08-20 00:27:28 +08:00
// CHECK-NEXT: 3: [B1.2](dummy(), 0)
// CHECK-NEXT: 4: (void)[B1.3] (CStyleCastExpr, ToVoid, void)
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B0
// CHECK: [B0 (EXIT)]
// CHECK-NEXT: Preds (1): B1
void testBuiltinSize() {
extern int *dummy();
(void)__builtin_object_size(dummy(), 0);
}
Add an implicit dtor CFG node just before C++ 'delete' expressions. This paves the way for adding support for modeling the destructor of a region before it is deleted. The statement "delete <expr>" now generates this series of CFG elements: 1. <expr> 2. [B1.1]->~Foo() (Implicit destructor) 3. delete [B1.1] Patch by Karthik Bhat! llvm-svn: 189828
2013-09-04 01:00:57 +08:00
class A {
public:
A() {}
~A() {}
};
[analyzer] Print function name when dumping its CFG. This allows us to use CHECK-LABEL to ensure that we're checking the right CFG. Debugging change only. llvm-svn: 199320
2014-01-16 01:25:05 +08:00
// CHECK-LABEL: void test_deletedtor()
Add an implicit dtor CFG node just before C++ 'delete' expressions. This paves the way for adding support for modeling the destructor of a region before it is deleted. The statement "delete <expr>" now generates this series of CFG elements: 1. <expr> 2. [B1.1]->~Foo() (Implicit destructor) 3. delete [B1.1] Patch by Karthik Bhat! llvm-svn: 189828
2013-09-04 01:00:57 +08:00
// CHECK: [B2 (ENTRY)]
// CHECK-NEXT: Succs (1): B1
// CHECK: [B1]
[analyzer] Add a CFG node for the allocator call in a C++ 'new' expression. In an expression like "new (a, b) Foo(x, y)", two things happen: - Memory is allocated by calling a function named 'operator new'. - The memory is initialized using the constructor for 'Foo'. Currently the analyzer only models the second event, though it has special cases for both the default and placement forms of operator new. This patch is the first step towards properly modeling both events: it changes the CFG so that the above expression now generates the following elements. 1. a 2. b 3. (CFGNewAllocator) 4. x 5. y 6. Foo::Foo The analyzer currently ignores the CFGNewAllocator element, but the next step is to treat that as a call like any other. The CFGNewAllocator element is not added to the CFG for analysis-based warnings, since none of them take advantage of it yet. llvm-svn: 199123
2014-01-14 01:59:19 +08:00
// CHECK-NEXT: 1: CFGNewAllocator(A *)
[CFG] Add extra context to C++ constructor statement elements. This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional information to provide regarding what sort of object is being constructed. It is useful for figuring out what memory is initialized in client of the CFG such as the Static Analyzer, which do not operate by recursive AST traversal, but instead rely on the CFG to provide all the information when they need it. Otherwise, the statement that triggers the construction and defines what memory is being initialized would normally occur after the construct-expression, and the client would need to peek to the next CFG element or use statement parent map to understand the necessary facts about the construct-expression. As a proof of concept, CFGConstructors are added for new-expressions and the respective test cases are provided to demonstrate how it works. For now, the only additional data contained in the CFGConstructor element is the "trigger statement", such as new-expression, which is the parent of the constructor. It will be significantly expanded in later commits. The additional data is organized as an auxiliary structure - the "construction context", which is allocated separately from the CFGElement. Differential Revision: https://reviews.llvm.org/D42672 llvm-svn: 324668
2018-02-09 06:58:15 +08:00
// WARNINGS-NEXT: 2: (CXXConstructExpr, class A)
// ANALYZER-NEXT: 2: (CXXConstructExpr, [B1.3], class A)
[analyzer] Add a CFG node for the allocator call in a C++ 'new' expression. In an expression like "new (a, b) Foo(x, y)", two things happen: - Memory is allocated by calling a function named 'operator new'. - The memory is initialized using the constructor for 'Foo'. Currently the analyzer only models the second event, though it has special cases for both the default and placement forms of operator new. This patch is the first step towards properly modeling both events: it changes the CFG so that the above expression now generates the following elements. 1. a 2. b 3. (CFGNewAllocator) 4. x 5. y 6. Foo::Foo The analyzer currently ignores the CFGNewAllocator element, but the next step is to treat that as a call like any other. The CFGNewAllocator element is not added to the CFG for analysis-based warnings, since none of them take advantage of it yet. llvm-svn: 199123
2014-01-14 01:59:19 +08:00
// CHECK-NEXT: 3: new A([B1.2])
// CHECK-NEXT: 4: A *a = new A();
// CHECK-NEXT: 5: a
// CHECK-NEXT: 6: [B1.5] (ImplicitCastExpr, LValueToRValue, class A *)
// CHECK-NEXT: 7: [B1.6]->~A() (Implicit destructor)
// CHECK-NEXT: 8: delete [B1.6]
Add an implicit dtor CFG node just before C++ 'delete' expressions. This paves the way for adding support for modeling the destructor of a region before it is deleted. The statement "delete <expr>" now generates this series of CFG elements: 1. <expr> 2. [B1.1]->~Foo() (Implicit destructor) 3. delete [B1.1] Patch by Karthik Bhat! llvm-svn: 189828
2013-09-04 01:00:57 +08:00
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B0
// CHECK: [B0 (EXIT)]
// CHECK-NEXT: Preds (1): B1
void test_deletedtor() {
A *a = new A();
delete a;
}
[analyzer] Print function name when dumping its CFG. This allows us to use CHECK-LABEL to ensure that we're checking the right CFG. Debugging change only. llvm-svn: 199320
2014-01-16 01:25:05 +08:00
// CHECK-LABEL: void test_deleteArraydtor()
Add an implicit dtor CFG node just before C++ 'delete' expressions. This paves the way for adding support for modeling the destructor of a region before it is deleted. The statement "delete <expr>" now generates this series of CFG elements: 1. <expr> 2. [B1.1]->~Foo() (Implicit destructor) 3. delete [B1.1] Patch by Karthik Bhat! llvm-svn: 189828
2013-09-04 01:00:57 +08:00
// CHECK: [B2 (ENTRY)]
// CHECK-NEXT: Succs (1): B1
// CHECK: [B1]
// CHECK-NEXT: 1: 5
[analyzer] Add a CFG node for the allocator call in a C++ 'new' expression. In an expression like "new (a, b) Foo(x, y)", two things happen: - Memory is allocated by calling a function named 'operator new'. - The memory is initialized using the constructor for 'Foo'. Currently the analyzer only models the second event, though it has special cases for both the default and placement forms of operator new. This patch is the first step towards properly modeling both events: it changes the CFG so that the above expression now generates the following elements. 1. a 2. b 3. (CFGNewAllocator) 4. x 5. y 6. Foo::Foo The analyzer currently ignores the CFGNewAllocator element, but the next step is to treat that as a call like any other. The CFGNewAllocator element is not added to the CFG for analysis-based warnings, since none of them take advantage of it yet. llvm-svn: 199123
2014-01-14 01:59:19 +08:00
// CHECK-NEXT: 2: CFGNewAllocator(A *)
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
// WARNINGS-NEXT: 3: (CXXConstructExpr, class A[5])
// ANALYZER-NEXT: 3: (CXXConstructExpr, [B1.4], class A[5])
[analyzer] Add a CFG node for the allocator call in a C++ 'new' expression. In an expression like "new (a, b) Foo(x, y)", two things happen: - Memory is allocated by calling a function named 'operator new'. - The memory is initialized using the constructor for 'Foo'. Currently the analyzer only models the second event, though it has special cases for both the default and placement forms of operator new. This patch is the first step towards properly modeling both events: it changes the CFG so that the above expression now generates the following elements. 1. a 2. b 3. (CFGNewAllocator) 4. x 5. y 6. Foo::Foo The analyzer currently ignores the CFGNewAllocator element, but the next step is to treat that as a call like any other. The CFGNewAllocator element is not added to the CFG for analysis-based warnings, since none of them take advantage of it yet. llvm-svn: 199123
2014-01-14 01:59:19 +08:00
// CHECK-NEXT: 4: new A {{\[\[}}B1.1]]
// CHECK-NEXT: 5: A *a = new A [5];
// CHECK-NEXT: 6: a
// CHECK-NEXT: 7: [B1.6] (ImplicitCastExpr, LValueToRValue, class A *)
// CHECK-NEXT: 8: [B1.7]->~A() (Implicit destructor)
// CHECK-NEXT: 9: delete [] [B1.7]
Add an implicit dtor CFG node just before C++ 'delete' expressions. This paves the way for adding support for modeling the destructor of a region before it is deleted. The statement "delete <expr>" now generates this series of CFG elements: 1. <expr> 2. [B1.1]->~Foo() (Implicit destructor) 3. delete [B1.1] Patch by Karthik Bhat! llvm-svn: 189828
2013-09-04 01:00:57 +08:00
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B0
// CHECK: [B0 (EXIT)]
// CHECK-NEXT: Preds (1): B1
void test_deleteArraydtor() {
A *a = new A[5];
delete[] a;
}
Avoid double edges when constructing CFGs Summary: If a noreturn destructor is executed while returning a value from a function, the resulting CFG has had two edges to the exit block. This crashed the analyzer, because it expects that blocks with no terminators have only one outgoing edge. I added code to avoid creating the second edge in this case. PS: The crashes did not manifest themselves always, as usually the NoReturnFunctionChecker would stop program evaluation before the analyzer hit the assertion, but in the case of lifetime extended temporaries, the checker failed to do that (which is a separate bug in itself). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1513 llvm-svn: 190125
2013-09-06 16:12:48 +08:00
namespace NoReturnSingleSuccessor {
struct A {
A();
~A();
};
struct B : public A {
B();
~B() __attribute__((noreturn));
};
[analyzer] Print function name when dumping its CFG. This allows us to use CHECK-LABEL to ensure that we're checking the right CFG. Debugging change only. llvm-svn: 199320
2014-01-16 01:25:05 +08:00
// CHECK-LABEL: int test1(int *x)
Avoid double edges when constructing CFGs Summary: If a noreturn destructor is executed while returning a value from a function, the resulting CFG has had two edges to the exit block. This crashed the analyzer, because it expects that blocks with no terminators have only one outgoing edge. I added code to avoid creating the second edge in this case. PS: The crashes did not manifest themselves always, as usually the NoReturnFunctionChecker would stop program evaluation before the analyzer hit the assertion, but in the case of lifetime extended temporaries, the checker failed to do that (which is a separate bug in itself). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1513 llvm-svn: 190125
2013-09-06 16:12:48 +08:00
// CHECK: 1: 1
// CHECK-NEXT: 2: return
[CFG] Make representation of destructor calls more accurate. Respect C++17 copy elision; previously it would generate destructor calls for elided temporaries, including in initialization and return statements. Don't generate duplicate destructor calls for statement expressions. Fix destructors in initialization lists and comma operators. Improve printing of implicit destructors. Patch by Nicholas Allegra! Differential Revision: https://reviews.llvm.org/D66404 llvm-svn: 370247
2019-08-29 02:44:42 +08:00
// CHECK-NEXT: ~NoReturnSingleSuccessor::B() (Implicit destructor)
Avoid double edges when constructing CFGs Summary: If a noreturn destructor is executed while returning a value from a function, the resulting CFG has had two edges to the exit block. This crashed the analyzer, because it expects that blocks with no terminators have only one outgoing edge. I added code to avoid creating the second edge in this case. PS: The crashes did not manifest themselves always, as usually the NoReturnFunctionChecker would stop program evaluation before the analyzer hit the assertion, but in the case of lifetime extended temporaries, the checker failed to do that (which is a separate bug in itself). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1513 llvm-svn: 190125
2013-09-06 16:12:48 +08:00
// CHECK-NEXT: Preds (1)
// CHECK-NEXT: Succs (1): B0
int test1(int *x) {
B b;
if (x)
return 1;
}
[analyzer] Print function name when dumping its CFG. This allows us to use CHECK-LABEL to ensure that we're checking the right CFG. Debugging change only. llvm-svn: 199320
2014-01-16 01:25:05 +08:00
// CHECK-LABEL: int test2(int *x)
Avoid double edges when constructing CFGs Summary: If a noreturn destructor is executed while returning a value from a function, the resulting CFG has had two edges to the exit block. This crashed the analyzer, because it expects that blocks with no terminators have only one outgoing edge. I added code to avoid creating the second edge in this case. PS: The crashes did not manifest themselves always, as usually the NoReturnFunctionChecker would stop program evaluation before the analyzer hit the assertion, but in the case of lifetime extended temporaries, the checker failed to do that (which is a separate bug in itself). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1513 llvm-svn: 190125
2013-09-06 16:12:48 +08:00
// CHECK: 1: 1
// CHECK-NEXT: 2: return
// CHECK-NEXT: destructor
// CHECK-NEXT: Preds (1)
// CHECK-NEXT: Succs (1): B0
int test2(int *x) {
const A& a = B();
if (x)
return 1;
}
}
Add CFG tests for switch's involving "extended" enum. llvm-svn: 197094
2013-12-12 07:44:05 +08:00
// Test CFG support for "extending" an enum.
[analyzer] Print function name when dumping its CFG. This allows us to use CHECK-LABEL to ensure that we're checking the right CFG. Debugging change only. llvm-svn: 199320
2014-01-16 01:25:05 +08:00
// CHECK-LABEL: int test_enum_with_extension(enum MyEnum value)
Add CFG tests for switch's involving "extended" enum. llvm-svn: 197094
2013-12-12 07:44:05 +08:00
// CHECK: [B7 (ENTRY)]
// CHECK-NEXT: Succs (1): B2
// CHECK: [B1]
// CHECK-NEXT: 1: x
// CHECK-NEXT: 2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
// CHECK-NEXT: 3: return [B1.2];
[CFG] record the original (now unreachable) block of 'case:' and 'default:' cases. llvm-svn: 202435
2014-02-28 05:56:44 +08:00
// CHECK-NEXT: Preds (5): B3 B4 B5 B6 B2(Unreachable)
Add CFG tests for switch's involving "extended" enum. llvm-svn: 197094
2013-12-12 07:44:05 +08:00
// CHECK-NEXT: Succs (1): B0
// CHECK: [B2]
// CHECK-NEXT: 1: 0
// CHECK-NEXT: 2: int x = 0;
// CHECK-NEXT: 3: value
// CHECK-NEXT: 4: [B2.3] (ImplicitCastExpr, LValueToRValue, enum MyEnum)
// CHECK-NEXT: 5: [B2.4] (ImplicitCastExpr, IntegralCast, int)
// CHECK-NEXT: T: switch [B2.5]
// CHECK-NEXT: Preds (1): B7
[CFG] record the original (now unreachable) block of 'case:' and 'default:' cases. llvm-svn: 202435
2014-02-28 05:56:44 +08:00
// CHECK-NEXT: Succs (5): B3 B4 B5 B6 B1(Unreachable)
Add CFG tests for switch's involving "extended" enum. llvm-svn: 197094
2013-12-12 07:44:05 +08:00
// CHECK: [B3]
// CHECK-NEXT: case D:
// CHECK-NEXT: 1: 4
// CHECK-NEXT: 2: x
// CHECK-NEXT: 3: [B3.2] = [B3.1]
// CHECK-NEXT: T: break;
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B1
// CHECK: [B4]
// CHECK-NEXT: case C:
// CHECK-NEXT: 1: 3
// CHECK-NEXT: 2: x
// CHECK-NEXT: 3: [B4.2] = [B4.1]
// CHECK-NEXT: T: break;
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B1
// CHECK: [B5]
// CHECK-NEXT: case B:
// CHECK-NEXT: 1: 2
// CHECK-NEXT: 2: x
// CHECK-NEXT: 3: [B5.2] = [B5.1]
// CHECK-NEXT: T: break;
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B1
// CHECK: [B6]
// CHECK-NEXT: case A:
// CHECK-NEXT: 1: 1
// CHECK-NEXT: 2: x
// CHECK-NEXT: 3: [B6.2] = [B6.1]
// CHECK-NEXT: T: break;
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B1
// CHECK: [B0 (EXIT)]
// CHECK-NEXT: Preds (1): B1
enum MyEnum { A, B, C };
static const enum MyEnum D = (enum MyEnum) 32;
int test_enum_with_extension(enum MyEnum value) {
int x = 0;
switch (value) {
case A: x = 1; break;
case B: x = 2; break;
case C: x = 3; break;
case D: x = 4; break;
}
return x;
}
[analyzer] Print function name when dumping its CFG. This allows us to use CHECK-LABEL to ensure that we're checking the right CFG. Debugging change only. llvm-svn: 199320
2014-01-16 01:25:05 +08:00
// CHECK-LABEL: int test_enum_with_extension_default(enum MyEnum value)
Add CFG tests for switch's involving "extended" enum. llvm-svn: 197094
2013-12-12 07:44:05 +08:00
// CHECK: [B7 (ENTRY)]
// CHECK-NEXT: Succs (1): B2
// CHECK: [B1]
// CHECK-NEXT: 1: x
// CHECK-NEXT: 2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
// CHECK-NEXT: 3: return [B1.2];
// CHECK-NEXT: Preds (4): B3 B4 B5 B6
// CHECK-NEXT: Succs (1): B0
// CHECK: [B2]
// CHECK-NEXT: 1: 0
// CHECK-NEXT: 2: int x = 0;
// CHECK-NEXT: 3: value
// CHECK-NEXT: 4: [B2.3] (ImplicitCastExpr, LValueToRValue, enum MyEnum)
// CHECK-NEXT: 5: [B2.4] (ImplicitCastExpr, IntegralCast, int)
// CHECK-NEXT: T: switch [B2.5]
// CHECK-NEXT: Preds (1): B7
[CFG] record the original (now unreachable) block of 'case:' and 'default:' cases. llvm-svn: 202435
2014-02-28 05:56:44 +08:00
// CHECK-NEXT: Succs (4): B4 B5 B6 B3(Unreachable)
Add CFG tests for switch's involving "extended" enum. llvm-svn: 197094
2013-12-12 07:44:05 +08:00
// CHECK: [B3]
// CHECK-NEXT: default:
// CHECK-NEXT: 1: 4
// CHECK-NEXT: 2: x
// CHECK-NEXT: 3: [B3.2] = [B3.1]
// CHECK-NEXT: T: break;
[CFG] record the original (now unreachable) block of 'case:' and 'default:' cases. llvm-svn: 202435
2014-02-28 05:56:44 +08:00
// CHECK-NEXT: Preds (1): B2(Unreachable)
Add CFG tests for switch's involving "extended" enum. llvm-svn: 197094
2013-12-12 07:44:05 +08:00
// CHECK-NEXT: Succs (1): B1
// CHECK: [B4]
// CHECK-NEXT: case C:
// CHECK-NEXT: 1: 3
// CHECK-NEXT: 2: x
// CHECK-NEXT: 3: [B4.2] = [B4.1]
// CHECK-NEXT: T: break;
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B1
// CHECK: [B5]
// CHECK-NEXT: case B:
// CHECK-NEXT: 1: 2
// CHECK-NEXT: 2: x
// CHECK-NEXT: 3: [B5.2] = [B5.1]
// CHECK-NEXT: T: break;
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B1
// CHECK: [B6]
// CHECK-NEXT: case A:
// CHECK-NEXT: 1: 1
// CHECK-NEXT: 2: x
// CHECK-NEXT: 3: [B6.2] = [B6.1]
// CHECK-NEXT: T: break;
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B1
// CHECK: [B0 (EXIT)]
// CHECK-NEXT: Preds (1): B1
int test_enum_with_extension_default(enum MyEnum value) {
int x = 0;
switch (value) {
case A: x = 1; break;
case B: x = 2; break;
case C: x = 3; break;
default: x = 4; break;
}
return x;
[analyzer] Add a CFG node for the allocator call in a C++ 'new' expression. In an expression like "new (a, b) Foo(x, y)", two things happen: - Memory is allocated by calling a function named 'operator new'. - The memory is initialized using the constructor for 'Foo'. Currently the analyzer only models the second event, though it has special cases for both the default and placement forms of operator new. This patch is the first step towards properly modeling both events: it changes the CFG so that the above expression now generates the following elements. 1. a 2. b 3. (CFGNewAllocator) 4. x 5. y 6. Foo::Foo The analyzer currently ignores the CFGNewAllocator element, but the next step is to treat that as a call like any other. The CFGNewAllocator element is not added to the CFG for analysis-based warnings, since none of them take advantage of it yet. llvm-svn: 199123
2014-01-14 01:59:19 +08:00
}
[analyzer] Print function name when dumping its CFG. This allows us to use CHECK-LABEL to ensure that we're checking the right CFG. Debugging change only. llvm-svn: 199320
2014-01-16 01:25:05 +08:00
// CHECK-LABEL: void test_placement_new()
[analyzer] Add a CFG node for the allocator call in a C++ 'new' expression. In an expression like "new (a, b) Foo(x, y)", two things happen: - Memory is allocated by calling a function named 'operator new'. - The memory is initialized using the constructor for 'Foo'. Currently the analyzer only models the second event, though it has special cases for both the default and placement forms of operator new. This patch is the first step towards properly modeling both events: it changes the CFG so that the above expression now generates the following elements. 1. a 2. b 3. (CFGNewAllocator) 4. x 5. y 6. Foo::Foo The analyzer currently ignores the CFGNewAllocator element, but the next step is to treat that as a call like any other. The CFGNewAllocator element is not added to the CFG for analysis-based warnings, since none of them take advantage of it yet. llvm-svn: 199123
2014-01-14 01:59:19 +08:00
// CHECK: [B2 (ENTRY)]
// CHECK-NEXT: Succs (1): B1
// CHECK: [B1]
// CHECK-NEXT: 1: int buffer[16];
// CHECK-NEXT: 2: buffer
// CHECK-NEXT: 3: [B1.2] (ImplicitCastExpr, ArrayToPointerDecay, int *)
// CHECK-NEXT: 4: [B1.3] (ImplicitCastExpr, BitCast, void *)
// CHECK-NEXT: 5: CFGNewAllocator(MyClass *)
[CFG] Add extra context to C++ constructor statement elements. This patch adds a new CFGStmt sub-class, CFGConstructor, which replaces the regular CFGStmt with CXXConstructExpr in it whenever the CFG has additional information to provide regarding what sort of object is being constructed. It is useful for figuring out what memory is initialized in client of the CFG such as the Static Analyzer, which do not operate by recursive AST traversal, but instead rely on the CFG to provide all the information when they need it. Otherwise, the statement that triggers the construction and defines what memory is being initialized would normally occur after the construct-expression, and the client would need to peek to the next CFG element or use statement parent map to understand the necessary facts about the construct-expression. As a proof of concept, CFGConstructors are added for new-expressions and the respective test cases are provided to demonstrate how it works. For now, the only additional data contained in the CFGConstructor element is the "trigger statement", such as new-expression, which is the parent of the constructor. It will be significantly expanded in later commits. The additional data is organized as an auxiliary structure - the "construction context", which is allocated separately from the CFGElement. Differential Revision: https://reviews.llvm.org/D42672 llvm-svn: 324668
2018-02-09 06:58:15 +08:00
// WARNINGS-NEXT: 6: (CXXConstructExpr, class MyClass)
// ANALYZER-NEXT: 6: (CXXConstructExpr, [B1.7], class MyClass)
[analyzer] Add a CFG node for the allocator call in a C++ 'new' expression. In an expression like "new (a, b) Foo(x, y)", two things happen: - Memory is allocated by calling a function named 'operator new'. - The memory is initialized using the constructor for 'Foo'. Currently the analyzer only models the second event, though it has special cases for both the default and placement forms of operator new. This patch is the first step towards properly modeling both events: it changes the CFG so that the above expression now generates the following elements. 1. a 2. b 3. (CFGNewAllocator) 4. x 5. y 6. Foo::Foo The analyzer currently ignores the CFGNewAllocator element, but the next step is to treat that as a call like any other. The CFGNewAllocator element is not added to the CFG for analysis-based warnings, since none of them take advantage of it yet. llvm-svn: 199123
2014-01-14 01:59:19 +08:00
// CHECK-NEXT: 7: new ([B1.4]) MyClass([B1.6])
// CHECK-NEXT: 8: MyClass *obj = new (buffer) MyClass();
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B0
// CHECK: [B0 (EXIT)]
// CHECK-NEXT: Preds (1): B1
extern void* operator new (unsigned long sz, void* v);
extern void* operator new[] (unsigned long sz, void* ptr);
class MyClass {
public:
MyClass() {}
~MyClass() {}
};
void test_placement_new() {
int buffer[16];
MyClass* obj = new (buffer) MyClass();
}
[analyzer] Print function name when dumping its CFG. This allows us to use CHECK-LABEL to ensure that we're checking the right CFG. Debugging change only. llvm-svn: 199320
2014-01-16 01:25:05 +08:00
// CHECK-LABEL: void test_placement_new_array()
[analyzer] Add a CFG node for the allocator call in a C++ 'new' expression. In an expression like "new (a, b) Foo(x, y)", two things happen: - Memory is allocated by calling a function named 'operator new'. - The memory is initialized using the constructor for 'Foo'. Currently the analyzer only models the second event, though it has special cases for both the default and placement forms of operator new. This patch is the first step towards properly modeling both events: it changes the CFG so that the above expression now generates the following elements. 1. a 2. b 3. (CFGNewAllocator) 4. x 5. y 6. Foo::Foo The analyzer currently ignores the CFGNewAllocator element, but the next step is to treat that as a call like any other. The CFGNewAllocator element is not added to the CFG for analysis-based warnings, since none of them take advantage of it yet. llvm-svn: 199123
2014-01-14 01:59:19 +08:00
// CHECK: [B2 (ENTRY)]
// CHECK-NEXT: Succs (1): B1
// CHECK: [B1]
// CHECK-NEXT: 1: int buffer[16];
// CHECK-NEXT: 2: buffer
// CHECK-NEXT: 3: [B1.2] (ImplicitCastExpr, ArrayToPointerDecay, int *)
// CHECK-NEXT: 4: [B1.3] (ImplicitCastExpr, BitCast, void *)
// CHECK-NEXT: 5: 5
// CHECK-NEXT: 6: CFGNewAllocator(MyClass *)
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
// WARNINGS-NEXT: 7: (CXXConstructExpr, class MyClass[5])
// ANALYZER-NEXT: 7: (CXXConstructExpr, [B1.8], class MyClass[5])
[analyzer] Add a CFG node for the allocator call in a C++ 'new' expression. In an expression like "new (a, b) Foo(x, y)", two things happen: - Memory is allocated by calling a function named 'operator new'. - The memory is initialized using the constructor for 'Foo'. Currently the analyzer only models the second event, though it has special cases for both the default and placement forms of operator new. This patch is the first step towards properly modeling both events: it changes the CFG so that the above expression now generates the following elements. 1. a 2. b 3. (CFGNewAllocator) 4. x 5. y 6. Foo::Foo The analyzer currently ignores the CFGNewAllocator element, but the next step is to treat that as a call like any other. The CFGNewAllocator element is not added to the CFG for analysis-based warnings, since none of them take advantage of it yet. llvm-svn: 199123
2014-01-14 01:59:19 +08:00
// CHECK-NEXT: 8: new ([B1.4]) MyClass {{\[\[}}B1.5]]
// CHECK-NEXT: 9: MyClass *obj = new (buffer) MyClass [5];
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B0
// CHECK: [B0 (EXIT)]
// CHECK-NEXT: Preds (1): B1
void test_placement_new_array() {
int buffer[16];
MyClass* obj = new (buffer) MyClass[5];
}
CFG: use Visit instead of VisitStmt to look through parens. PR18472 llvm-svn: 199227
2014-01-15 01:29:12 +08:00
Fix some cases of incorrect handling of lifetime extended temporaries. MaterializeTemporaryExpr already contains information about the lifetime of the temporary; if the lifetime is not the full statement, we do not want to emit a destructor at the end of the full statement for it. llvm-svn: 214292
2014-07-30 16:34:42 +08:00
// CHECK-LABEL: void test_lifetime_extended_temporaries()
// CHECK: [B1]
struct LifetimeExtend { LifetimeExtend(int); ~LifetimeExtend(); };
struct Aggregate { const LifetimeExtend a; const LifetimeExtend b; };
struct AggregateRef { const LifetimeExtend &a; const LifetimeExtend &b; };
void test_lifetime_extended_temporaries() {
// CHECK: LifetimeExtend(1);
// CHECK-NEXT: : 1
// CHECK-NEXT: ~LifetimeExtend()
// CHECK-NOT: ~LifetimeExtend()
{
const LifetimeExtend &l = LifetimeExtend(1);
1;
}
// CHECK: LifetimeExtend(2)
// CHECK-NEXT: ~LifetimeExtend()
// CHECK-NEXT: : 2
// CHECK-NOT: ~LifetimeExtend()
{
// No life-time extension.
const int &l = (LifetimeExtend(2), 2);
2;
}
// CHECK: LifetimeExtend(3)
// CHECK-NEXT: : 3
// CHECK-NEXT: ~LifetimeExtend()
// CHECK-NOT: ~LifetimeExtend()
{
// The last one is lifetime extended.
const LifetimeExtend &l = (3, LifetimeExtend(3));
3;
}
// CHECK: LifetimeExtend(4)
// CHECK-NEXT: ~LifetimeExtend()
// CHECK-NEXT: ~LifetimeExtend()
// CHECK-NEXT: : 4
// CHECK-NOT: ~LifetimeExtend()
{
Aggregate a{LifetimeExtend(4), LifetimeExtend(4)};
4;
}
// CHECK: LifetimeExtend(5)
// CHECK-NEXT: : 5
// FIXME: We want to emit the destructors of the lifetime
// extended variables here.
// CHECK-NOT: ~LifetimeExtend()
{
AggregateRef a{LifetimeExtend(5), LifetimeExtend(5)};
5;
}
// FIXME: Add tests for lifetime extension via subobject
// references (LifetimeExtend().some_member).
}
[analyzer] pr37688: Fix a crash upon evaluating a deleted destructor of a union. Add a defensive check against an invalid destructor in the CFG. Unions with fields with destructors have their own destructor implicitly deleted. Due to a bug in the CFG we're still trying to evaluate them at the end of the object's lifetime and crash because we are unable to find the destructor's declaration. rdar://problem/47362608 Differential Revision: https://reviews.llvm.org/D56899 llvm-svn: 351610
2019-01-19 07:05:07 +08:00
// FIXME: The destructor for 'a' shouldn't be there because it's deleted
// in the union.
// CHECK-LABEL: void foo()
// CHECK: [B2 (ENTRY)]
// CHECK-NEXT: Succs (1): B1
// CHECK: [B1]
// WARNINGS-NEXT: 1: (CXXConstructExpr, struct pr37688_deleted_union_destructor::A)
// ANALYZER-NEXT: 1: (CXXConstructExpr, [B1.2], struct pr37688_deleted_union_destructor::A)
// CHECK-NEXT: 2: pr37688_deleted_union_destructor::A a;
[CFG] Make representation of destructor calls more accurate. Respect C++17 copy elision; previously it would generate destructor calls for elided temporaries, including in initialization and return statements. Don't generate duplicate destructor calls for statement expressions. Fix destructors in initialization lists and comma operators. Improve printing of implicit destructors. Patch by Nicholas Allegra! Differential Revision: https://reviews.llvm.org/D66404 llvm-svn: 370247
2019-08-29 02:44:42 +08:00
// CHECK-NEXT: 3: [B1.2].~pr37688_deleted_union_destructor::A() (Implicit destructor)
[analyzer] pr37688: Fix a crash upon evaluating a deleted destructor of a union. Add a defensive check against an invalid destructor in the CFG. Unions with fields with destructors have their own destructor implicitly deleted. Due to a bug in the CFG we're still trying to evaluate them at the end of the object's lifetime and crash because we are unable to find the destructor's declaration. rdar://problem/47362608 Differential Revision: https://reviews.llvm.org/D56899 llvm-svn: 351610
2019-01-19 07:05:07 +08:00
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B0
// CHECK: [B0 (EXIT)]
// CHECK-NEXT: Preds (1): B1
namespace pr37688_deleted_union_destructor {
struct S { ~S(); };
struct A {
~A() noexcept {}
union {
struct {
S s;
} ss;
};
};
void foo() {
A a;
}
} // end namespace pr37688_deleted_union_destructor
[CFG] Fix CFG for statement-expressions in return values. We're building the CFG from bottom to top, so when the return-value expression has a non-trivial CFG on its own, we need to continue building from the entry to the return-value expression CFG rather than from the block to which we've just appended the return statement. Fixes a false positive warning "control may reach end of non-void function". llvm-svn: 370406
2019-08-30 04:37:28 +08:00
namespace return_statement_expression {
int unknown();
// CHECK-LABEL: int foo()
// CHECK: [B6 (ENTRY)]
// CHECK-NEXT: Succs (1): B5
// CHECK: [B1]
// CHECK-NEXT: 1: 0
// CHECK-NEXT: 2: return [B1.1];
// CHECK-NEXT: Preds (1): B5
// CHECK-NEXT: Succs (1): B0
// CHECK: [B2]
// CHECK-NEXT: 1: 0
// CHECK-NEXT: 2: ({ ... ; [B2.1] })
// CHECK-NEXT: 3: return [B2.2];
// CHECK-NEXT: Preds (1): B4
// CHECK-NEXT: Succs (1): B0
// FIXME: Why do we have [B3] at all?
// CHECK: [B3]
// CHECK-NEXT: Succs (1): B4
// CHECK: [B4]
// CHECK-NEXT: 1: 0
// CHECK-NEXT: 2: [B4.1] (ImplicitCastExpr, IntegralToBoolean, _Bool)
// CHECK-NEXT: T: while [B4.2]
// CHECK-NEXT: Preds (2): B3 B5
// CHECK-NEXT: Succs (2): NULL B2
// CHECK: [B5]
// CHECK-NEXT: 1: unknown
// CHECK-NEXT: 2: [B5.1] (ImplicitCastExpr, FunctionToPointerDecay, int (*)(void))
// CHECK-NEXT: 3: [B5.2]()
// CHECK-NEXT: 4: [B5.3] (ImplicitCastExpr, IntegralToBoolean, _Bool)
// CHECK-NEXT: T: if [B5.4]
// CHECK-NEXT: Preds (1): B6
// CHECK-NEXT: Succs (2): B4 B1
// CHECK: [B0 (EXIT)]
// CHECK-NEXT: Preds (2): B1 B2
int foo() {
if (unknown())
return ({
while (0)
;
0;
});
else
return 0;
}
} // namespace statement_expression_in_return
[Analyzer] Include typedef statements in CFG build. Summary: Array size expressions in typedef statements with a VLA (variable-length array) are handled from now as in plain (non-typedef) VLA declarations. Type-aliases with VLA are handled too (but main focus is on C code). Reviewers: Szelethus, aaron.ballman, NoQ, xazax.hun Reviewed By: aaron.ballman, xazax.hun Subscribers: rnkovacs, NoQ, efriedma, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77809
2020-04-27 15:45:38 +08:00
// CHECK-LABEL: void vla_simple(int x)
// CHECK: [B1]
Improve -Wtautological-overlap-compare Allow this warning to detect a larger number of constant values, including negative numbers, and handle non-int types better. Differential Revision: https://reviews.llvm.org/D66044 llvm-svn: 372448
2019-09-21 10:37:10 +08:00
// CHECK-NEXT: 1: x
[Analyzer] Include typedef statements in CFG build. Summary: Array size expressions in typedef statements with a VLA (variable-length array) are handled from now as in plain (non-typedef) VLA declarations. Type-aliases with VLA are handled too (but main focus is on C code). Reviewers: Szelethus, aaron.ballman, NoQ, xazax.hun Reviewed By: aaron.ballman, xazax.hun Subscribers: rnkovacs, NoQ, efriedma, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77809
2020-04-27 15:45:38 +08:00
// CHECK-NEXT: 2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
// CHECK-NEXT: 3: int vla[x];
void vla_simple(int x) {
int vla[x];
}
// CHECK-LABEL: void vla_typedef(int x)
// CHECK: [B1]
// CHECK-NEXT: 1: x
// CHECK-NEXT: 2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
// CHECK-NEXT: 3: typedef int VLA[x];
void vla_typedef(int x) {
typedef int VLA[x];
}
// CHECK-LABEL: void vla_typealias(int x)
// CHECK: [B1]
// CHECK-NEXT: 1: x
// CHECK-NEXT: 2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
// CHECK-NEXT: 3: using VLA = int[x];
[Analyzer] Include typedef statements in CFG build. Summary: Array size expressions in typedef statements with a VLA (variable-length array) are handled from now as in plain (non-typedef) VLA declarations. Type-aliases with VLA are handled too (but main focus is on C code). Reviewers: Szelethus, aaron.ballman, NoQ, xazax.hun Reviewed By: aaron.ballman, xazax.hun Subscribers: rnkovacs, NoQ, efriedma, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77809
2020-04-27 15:45:38 +08:00
void vla_typealias(int x) {
using VLA = int[x];
}
// CHECK-LABEL: void vla_typedef_multi(int x, int y)
// CHECK: [B1]
// CHECK-NEXT: 1: y
// CHECK-NEXT: 2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
// CHECK-NEXT: 3: x
// CHECK-NEXT: 4: [B1.3] (ImplicitCastExpr, LValueToRValue, int)
// CHECK-NEXT: 5: typedef int VLA[x][y];
void vla_typedef_multi(int x, int y) {
typedef int VLA[x][y];
}
// CHECK-LABEL: void vla_typedefname_multi(int x, int y)
// CHECK: [B1]
// CHECK-NEXT: 1: x
// CHECK-NEXT: 2: [B1.1] (ImplicitCastExpr, LValueToRValue, int)
// CHECK-NEXT: 3: typedef int VLA[x];
// CHECK-NEXT: 4: y
// CHECK-NEXT: 5: [B1.4] (ImplicitCastExpr, LValueToRValue, int)
// CHECK-NEXT: 6: typedef VLA VLA1[y];
// CHECK-NEXT: 7: 3
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
// CHECK-NEXT: 8: using VLA2 = VLA1[3];
[Analyzer] Include typedef statements in CFG build. Summary: Array size expressions in typedef statements with a VLA (variable-length array) are handled from now as in plain (non-typedef) VLA declarations. Type-aliases with VLA are handled too (but main focus is on C code). Reviewers: Szelethus, aaron.ballman, NoQ, xazax.hun Reviewed By: aaron.ballman, xazax.hun Subscribers: rnkovacs, NoQ, efriedma, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77809
2020-04-27 15:45:38 +08:00
// CHECK-NEXT: 9: 4
// CHECK-NEXT: 10: VLA2 vla[4];
void vla_typedefname_multi(int x, int y) {
typedef int VLA[x];
typedef VLA VLA1[y];
using VLA2 = VLA1[3];
VLA2 vla[4];
}
// CHECK-LABEL: int vla_evaluate(int x)
// CHECK: [B1]
// CHECK-NEXT: 1: x
// CHECK-NEXT: 2: ++[B1.1]
// CHECK-NEXT: 3: [B1.2] (ImplicitCastExpr, LValueToRValue, int)
// CHECK-NEXT: 4: typedef int VLA[++x];
// CHECK-NEXT: 5: x
// CHECK-NEXT: 6: ++[B1.5]
// CHECK-NEXT: 7: [B1.6] (ImplicitCastExpr, LValueToRValue, int)
Recommit: Compress formatting of array type names (int [4] -> int[4]) Based on post-commit review discussion on 2bd84938470bf2e337801faafb8a67710f46429d with Richard Smith. Other uses of forcing HasEmptyPlaceHolder to false seem OK to me - they're all around pointer/reference types where the pointer/reference token will appear at the rightmost side of the left side of the type name, so they make nested types (eg: the "int" in "int *") behave as though there is a non-empty placeholder (because the "*" is essentially the placeholder as far as the "int" is concerned). This was originally committed in 277623f4d5a672d707390e2c3eaf30a9eb4b075c Reverted in f9ad1d1c775a8e264bebc15d75e0c6e5c20eefc7 due to breakages outside of clang - lldb seems to have some strange/strong dependence on "char [N]" versus "char[N]" when printing strings (not due to that name appearing in DWARF, but probably due to using clang to stringify type names) that'll need to be addressed, plus a few other odds and ends in other subprojects (clang-tools-extra, compiler-rt, etc).
2021-10-15 05:52:47 +08:00
// CHECK-NEXT: 8: sizeof(int[++x])
// CHECK-NEXT: 9: alignof(int[++x])
[Analyzer] Include typedef statements in CFG build. Summary: Array size expressions in typedef statements with a VLA (variable-length array) are handled from now as in plain (non-typedef) VLA declarations. Type-aliases with VLA are handled too (but main focus is on C code). Reviewers: Szelethus, aaron.ballman, NoQ, xazax.hun Reviewed By: aaron.ballman, xazax.hun Subscribers: rnkovacs, NoQ, efriedma, xazax.hun, baloghadamsoftware, szepet, a.sidorin, mikhail.ramalho, Szelethus, donat.nagy, dkrupp, gamesh411, Charusso, martong, ASDenysPetrov, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D77809
2020-04-27 15:45:38 +08:00
// CHECK-NEXT: 10: 0
// CHECK-NEXT: 11: x
// CHECK-NEXT: 12: [B1.11] (ImplicitCastExpr, LValueToRValue, int)
// CHECK-NEXT: 13: return [B1.12];
int vla_evaluate(int x) {
// Evaluates the ++x
typedef int VLA[++x];
sizeof(int[++x]);
// Do not evaluate the ++x
_Alignof(int[++x]);
_Generic((int(*)[++x])0, default : 0);
return x;
Improve -Wtautological-overlap-compare Allow this warning to detect a larger number of constant values, including negative numbers, and handle non-int types better. Differential Revision: https://reviews.llvm.org/D66044 llvm-svn: 372448
2019-09-21 10:37:10 +08:00
}
CFG: Destroy temporaries in (a,b) expression in the correct order.
2020-08-06 05:52:24 +08:00
// CHECK-LABEL: void CommaTemp::f()
// CHECK: [B1]
// CHECK-NEXT: 1: CommaTemp::A() (CXXConstructExpr,
// CHECK-NEXT: 2: [B1.1] (BindTemporary)
// CHECK-NEXT: 3: CommaTemp::B() (CXXConstructExpr,
// CHECK-NEXT: 4: [B1.3] (BindTemporary)
// CHECK-NEXT: 5: ... , [B1.4]
// CHECK-NEXT: 6: ~CommaTemp::B() (Temporary object destructor)
// CHECK-NEXT: 7: ~CommaTemp::A() (Temporary object destructor)
namespace CommaTemp {
struct A { ~A(); };
struct B { ~B(); };
void f();
}
void CommaTemp::f() {
A(), B();
}
Make output of -ast-print a valid C++ code. Output generated by option -ast-print looks like C/C++ code, and it really is for plain C. For C++ the produced output was not valid C++ code, but the differences were small. With this change the output is fixed and can be compiled. Tests are changed so that output produced by -ast-print is compiled again with the same flags and both outputs are compared. Option -ast-print is extensively used in clang tests but it itself was tested poorly, existing tests only checked that compiler did not crash. There are unit tests in file DeclPrinterTest.cpp, but they test only terse output mode. Differential Revision: https://reviews.llvm.org/D26452 llvm-svn: 286439
2016-11-10 16:49:37 +08:00
// CHECK-LABEL: template<> int *PR18472<int>()
CFG: use Visit instead of VisitStmt to look through parens. PR18472 llvm-svn: 199227
2014-01-15 01:29:12 +08:00
// CHECK: [B2 (ENTRY)]
// CHECK-NEXT: Succs (1): B1
// CHECK: [B1]
// CHECK-NEXT: 1: 0
// CHECK-NEXT: 2: [B1.1] (ImplicitCastExpr, NullToPointer, PR18472_t)
// CHECK-NEXT: 3: (PR18472_t)[B1.2] (CStyleCastExpr, NoOp, PR18472_t)
// CHECK-NEXT: 4: CFGNewAllocator(int *)
// CHECK-NEXT: 5: new (([B1.3])) int
// CHECK-NEXT: 6: return [B1.5];
// CHECK-NEXT: Preds (1): B2
// CHECK-NEXT: Succs (1): B0
// CHECK: [B0 (EXIT)]
// CHECK-NEXT: Preds (1): B1
extern "C" typedef int *PR18472_t;
void *operator new (unsigned long, PR18472_t);
template <class T> T *PR18472() {
return new (((PR18472_t) 0)) T;
}
void PR18472_helper() {
PR18472<int>();
}