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/NewDelete-path-notes.cpp

488 lines
21 KiB
C++
Raw Normal View History

[analyzer] Re-enable cplusplus.NewDelete (but not NewDeleteLeaks). As mentioned in the previous commit message, the use-after-free and double-free warnings for 'delete' are worth enabling even while the leak warnings still have false positives. llvm-svn: 178891
2013-04-06 01:55:07 +08:00
// RUN: %clang_cc1 -analyze -analyzer-checker=cplusplus.NewDelete,unix.Malloc -analyzer-output=text -verify %s
[analyzer] Enable the new edge algorithm by default. ...but don't yet migrate over the existing plist tests. Some of these would be trivial to migrate; others could use a bit of inspection first. In any case, though, the new edge algorithm seems to have proven itself, and we'd like more coverage (and more usage) of it going forwards. llvm-svn: 183165
2013-06-04 07:00:19 +08:00
// RUN: %clang_cc1 -analyze -analyzer-checker=cplusplus.NewDelete,unix.Malloc -analyzer-output=plist -analyzer-config path-diagnostics-alternate=false %s -o %t.plist
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// RUN: FileCheck --input-file=%t.plist %s
void test() {
int *p = new int;
// expected-note@-1 {{Memory is allocated}}
if (p)
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// expected-note@-1 {{Taking true branch}}
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
delete p;
// expected-note@-1 {{Memory is released}}
delete p; // expected-warning {{Attempt to free released memory}}
// expected-note@-1 {{Attempt to free released memory}}
}
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
struct Odd {
void kill() {
delete this; // expected-note {{Memory is released}}
}
};
void test(Odd *odd) {
odd->kill(); // expected-note{{Calling 'Odd::kill'}}
// expected-note@-1 {{Returning; memory was released}}
delete odd; // expected-warning {{Attempt to free released memory}}
// expected-note@-1 {{Attempt to free released memory}}
}
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK: <key>diagnostics</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>path</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>6</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>6</integer>
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>6</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>6</integer>
// CHECK-NEXT: <key>col</key><integer>14</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <dict>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>line</key><integer>6</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: </dict>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>ranges</key>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <array>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>6</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>6</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>18</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Memory is allocated</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Memory is allocated</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>6</integer>
// CHECK-NEXT: <key>col</key><integer>12</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>6</integer>
// CHECK-NEXT: <key>col</key><integer>14</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>8</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>8</integer>
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>8</integer>
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>line</key><integer>8</integer>
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>10</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>10</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>10</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>10</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>10</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>12</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Memory is released</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Memory is released</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>10</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>10</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>10</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Attempt to free released memory</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Attempt to free released memory</string>
// CHECK-NEXT: </dict>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: </array>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>description</key><string>Attempt to free released memory</string>
// CHECK-NEXT: <key>category</key><string>Memory Error</string>
// CHECK-NEXT: <key>type</key><string>Double free</string>
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>test</string>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>issue_hash</key><string>8</string>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>13</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>path</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>24</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>2</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>24</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>2</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>24</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>12</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Calling &apos;Odd::kill&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Calling &apos;Odd::kill&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>2</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>depth</key><integer>1</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Entered call from &apos;test&apos;</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Entered call from &apos;test&apos;</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>2</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>18</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>5</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>8</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>3</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>19</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>13</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>depth</key><integer>1</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Memory is released</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Memory is released</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>24</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>2</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>24</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>2</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>24</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>12</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Returning; memory was released</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Returning; memory was released</string>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>control</string>
// CHECK-NEXT: <key>edges</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>start</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>24</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>2</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>24</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>4</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: <key>end</key>
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>26</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>2</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>26</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>7</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
// CHECK-NEXT: <key>kind</key><string>event</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>26</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>2</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <key>ranges</key>
// CHECK-NEXT: <array>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <array>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>26</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>2</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>26</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>11</integer>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>
// CHECK-NEXT: </array>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>depth</key><integer>0</integer>
// CHECK-NEXT: <key>extended_message</key>
// CHECK-NEXT: <string>Attempt to free released memory</string>
// CHECK-NEXT: <key>message</key>
// CHECK-NEXT: <string>Attempt to free released memory</string>
// CHECK-NEXT: </dict>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: </array>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>description</key><string>Attempt to free released memory</string>
// CHECK-NEXT: <key>category</key><string>Memory Error</string>
// CHECK-NEXT: <key>type</key><string>Double free</string>
// CHECK-NEXT: <key>issue_context_kind</key><string>function</string>
// CHECK-NEXT: <key>issue_context</key><string>test</string>
// CHECK-NEXT: <key>issue_hash</key><string>3</string>
// CHECK-NEXT: <key>location</key>
// CHECK-NEXT: <dict>
[analyzer] Assume new returns non-null even under -fno-exceptions Summary: -fno-exceptions does not implicitly attach a nothrow specifier to every operator new. Even in this mode, non-nothrow new must not return a null pointer. Failure to allocate memory can be signalled by other means, or just by killing the program. This behaviour is consistent with the compiler - even with -fno-exceptions, the generated code never tests for null (and would segfault if the opeator actually happened to return null). Reviewers: jordan_rose CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D1528 llvm-svn: 189452
2013-08-28 16:04:08 +08:00
// CHECK-NEXT: <key>line</key><integer>26</integer>
[analyzer] Improve the malloc checker stack hint message llvm-svn: 179580
2013-04-16 08:22:55 +08:00
// CHECK-NEXT: <key>col</key><integer>2</integer>
// CHECK-NEXT: <key>file</key><integer>0</integer>
// CHECK-NEXT: </dict>
[analyzer] Adds cplusplus.NewDelete checker that check for memory leaks, double free, and use-after-free problems of memory managed by new/delete. llvm-svn: 177849
2013-03-25 09:35:45 +08:00
// CHECK-NEXT: </dict>
// CHECK-NEXT: </array>