Apr 30 2015
Apr 29 2015
Fixed an issue with spaces. However additional changes (support for spaces in compiler arguments) are required to fully support spaces in a compiler path.
Giving --use-analyzer="F:/C LANG/clang.exe" to scan-build ends up with
error: error reading 'LANG\..\lib\clang\3.7.0'
That's because -resource-dir F:\C LANG\..\lib\clang\3.7.0 is given to clang.
Apr 20 2015
Tested the patch more carefully - tested combinations of different options. Also launched scan-build over real codebases - LLVM and OGRE. No regressions found.
Apr 15 2015
Committed as r234889.
Apr 14 2015
Apr 10 2015
Apr 3 2015
and, last but not least, the CR are broken. I don't know what you use but it seems that patch detects it as binary.
Apr 1 2015
The second patch does not apply on top of the first.
Yes, these patches are not cumulative. After one of the patches gets in the other must be modified.
+ added cfe-commits to the subscribers list.
Mar 30 2015
"Prevent ccc/c++-analyzer from hanging on Windows." is up to date:
Note, this patch is not included in the refactoring patch.
Mar 26 2015
Anna, sorry, mistaken, all of this is just a refactoring, including the line 1254.
Anna, just a refactoring, except line 1254 where missing "-Xclang" added before "-load". I'll make a separate patch for this.
+ refactoring: moved processing of command-line arguments to a subroutine.
Mar 21 2015
New patch with comments addressed, please review!
Thanks for review!
Mar 18 2015
Updated the patch, made the checker stateless, please review!
Mar 12 2015
Aaa, I see, thank you!
Mar 11 2015
Mar 10 2015
Mar 6 2015
Mar 4 2015
Mar 3 2015
Feb 19 2015
Feb 17 2015
Feb 10 2015
Jan 7 2015
Added the comment (inlined comment at MallocChecker.cpp, Line 259). OK to commit?
Dec 28 2014
"Have you added a test to make sure that is the case? (If yes, what's the function name. I could not easily find it.) It would be similar to the path-sensitive check you've added but the check against '0' would be done in an inlined function."
Done, 'void testMallocIdc(int i)' added.
Dec 23 2014
Dec 17 2014
Dec 16 2014
Dec 10 2014
Updated the patch.
Addressed the comments, updated the patch, please review!
Dec 5 2014
Nov 7 2014
Oct 21 2014
Committed at r220289.
Oct 14 2014
Sep 24 2014
The discussion moved to llvmdev, topic "New type of smart pointer for LLVM"
It also doesn't compose with other deleters, which is a little unfortunate.
All is needed to do to make an existing deleter work with unique_ptr_deferred_release is to inherit the deleter from a 'SwitchControlledDeleterBase' class ('Switch' class in the new patch).
Sep 22 2014
Sep 16 2014
Cleaned the patch.
Anna, Ted, do you think the NeweleteLeaks checker is ready for being turned on?
Sep 11 2014
Attached is the report with all the leaks from the last analyzer run (10.09.2014) addressed. Minimal tests are included for all types of false-positives.
Aug 5 2014
Committed as r214909.
Aug 4 2014
Attached are leak reports generated by NewDeleteLeaks checker ran over
the LLVM codebase with -analyzer-opt-analyze-headers option turned on.
Haven't addressed them yet. Looking at suspicious leak reports generated
from headers (e.g. reports from TinyPtrVector.h).
Done! Ok to commit?
Just ran the updated NewDeleteLeaks checker over LLVM codebase with -analyzer-opt-analyze-headers option turned on. Failed to attach reports in Phabricator, I'll send them with the next mail.
Aug 1 2014
Jul 23 2014
Simplified the check, an un-consumed new is now treated a leak unless the constructor has a parameter of a pointer-to-record type. The check is not expensive and covers LLVM cases.
Jul 16 2014
Now searching on the class and all superclasses that has methods accessible from the constructed record. Referenced types are now cached.
Jun 4 2014
May 19 2014
The expandcollapse.js is written by me from scratch as well as button images. Committed as r209131.
May 12 2014
May 5 2014
Update to the patch after r207995. Enabling of the expandcollapse feature added.
Substituted the second example with the one that uses a destructor call.
References to sub-objects used after the destructor has been called are the matter of undefbehavior.MemberRefAfterDtor. Reinitialization of an object whose destructor hasn't been called is a good idea for an another checker!
This checker is designed for the particular cases described in C++03 3.8p5, p7 and C++11 3.8p5, p7.
May 2 2014
Not sure that I've got the idea. Each example is designed for the particular case of a dangerous pointer usage. In order:
The first example illustrates the usage of a pointer as an operand of a delete-expression - OK.
The second example is a modified example from the C++ spec - a call to a virtual function of an object whose lifetime has ended. Did you mean to call a destructor or keep a pointer to a field within the object instead? Isn't a call to a virtual function a usage of an old object?
The last three examples illustrate the following cases:
- the pointer is implicitly converted to a pointer to a base class type
- the pointer is used as the operand of a static_cast (except when the conversion is to void*, or to void* and subsequently to char*, or unsigned char*)
- the pointer is used as the operand of a dynamic_cast
Do you think the corresponding tests should be modified somehow?
Apr 29 2014
Thanks for committing this! My fault, did not included alpha_checks.html, implicit_checks.html and expandcollapse.js to the previous patch.
Additionally fixed table headers in available_checks.html, fixed paddings/margins of all table headers and updated undefbehavior.DeadReferenced.