| 651f13cea278ec967336033dd032faef0e9fc2ec |
|
24-Apr-2014 |
Stephen Hines <srhines@google.com> |
Updated to Clang 3.5a.
Change-Id: I8127eb568f674c2e72635b639a3295381fe8af82
/external/clang/test/Analysis/inlining/stl.cpp
|
| fda9dbf1f4d15baaedffdd4b4bb529e06172f73d |
|
15-Nov-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] Silence warnings coming from allocators used by std::basic_string.
This is similar to r194004: because we can't reason about the data structure
invariants of std::basic_string, the analyzer decides it's possible for an
allocator to be used to deallocate the string's inline storage. Just ignore
this by walking up the stack, skipping past methods in classes with
"allocator" in the name, and seeing if we reach std::basic_string that way.
PR17866
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194764 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/stl.cpp
|
| bdc0bf3f84b8771572d8401c66903c56a2e1318e |
|
04-Nov-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] Suppress warnings coming out of std::basic_string.
The analyzer cannot reason about the internal invariances of the data structure (radar://15194597).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194004 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/stl.cpp
|
| 8b625a3f7764959d0a2ac3cd860ce1e168e0fc9b |
|
04-Jul-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] Suppress reports reported in std::list
The motivation is to suppresses false use-after-free reports that occur when calling
std::list::pop_front() or std::list::pop_back() twice. The analyzer does not
reason about the internal invariants of the list implementation, so just do not report
any of warnings in std::list.
Fixes radar://14317928.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185609 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/stl.cpp
|
| c63a460d78a7625ff38d2b3580f78030c44f07db |
|
02-Apr-2013 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] For now, don't inline [cd]tors of C++ containers.
This is a heuristic to make up for the fact that the analyzer doesn't
model C++ containers very well. One example is modeling that
'std::distance(I, E) == 0' implies 'I == E'. In the future, it would be
nice to model this explicitly, but for now it just results in a lot of
false positives.
The actual heuristic checks if the base type has a member named 'begin' or
'iterator'. If so, we treat the constructors and destructors of that type
as opaque, rather than inlining them.
This is intended to drastically reduce the number of false positives
reported with experimental destructor support turned on. We can tweak the
heuristic in the future, but we'd rather err on the side of false negatives
for now.
<rdar://problem/13497258>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178516 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/stl.cpp
|
| bfa9ab8183e2fdc74f8633d758cb0c6201314320 |
|
25-Jan-2013 |
Anna Zaks <ganna@apple.com> |
[analyzer] Replace "-analyzer-ipa" with "-analyzer-config ipa".
The idea is to eventually place all analyzer options under
"analyzer-config". In addition, this lays the ground for introduction of
a high-level analyzer mode option, which will influence the
default setting for IPAMode.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173385 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/stl.cpp
|
| 1b22cec353bc6112653d50b060a1d78d70c51527 |
|
12-Sep-2012 |
Chandler Carruth <chandlerc@gmail.com> |
Adjust some analyzer tests to place widely shared inputs inside of an
'Inputs' subdirectory.
The general desire has been to have essentially all of the non-test
input files live in such directories, with some exceptions for obvious
and common patterns like 'foo.c' using 'foo.h'.
This came up because our distributed test runner couldn't find some of
the headers, for example with stl.cpp.
No functionality changed, just shuffling around here.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163674 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/stl.cpp
|
| e08dcbe75eb9b3ffe6f1f60ac2b216b4c878606a |
|
11-Sep-2012 |
Anna Zaks <ganna@apple.com> |
[analyzer] Turn stl inlining back on.
The one reported bug, which was exposed by stl inlining, is addressed in
r163558.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163574 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/stl.cpp
|
| 81fb50e8b120fc95dc0245b4112972d4d7cca3b5 |
|
10-Sep-2012 |
Jordan Rose <jordan_rose@apple.com> |
[analyzer] For now, don't inline C++ standard library functions.
This is a (heavy-handed) solution to PR13724 -- until we know we can do
a good job inlining the STL, it's best to be consistent and not generate
more false positives than we did before. We can selectively whitelist
certain parts of the 'std' namespace that are known to be safe.
This is controlled by analyzer config option 'c++-stdlib-inlining', which
can be set to "true" or "false".
This commit also adds control for whether or not to inline any templated
functions (member or non-member), under the config option
'c++-template-inlining'. This option is currently on by default.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163548 91177308-0d34-0410-b5e6-96231b3b80d8
/external/clang/test/Analysis/inlining/stl.cpp
|