Summary:
Handle C++ method declarations and create cfgs for them.
Doesn't do:
Method calls (CXXMethodCall)
Using `this` expression in methods (including implicit ones)
Summary:
Refactor of creating method signatures. First step to use the map of pointers to find method declarations.
The idea is to have a function that creates a method signature from a declaration, later we can get the declaration from a pointer
and use this function to retrieve the method signature.
(authored by @dulmarod)
Summary:
Add basic translation for C++ `new` keyword.
Currently, it's modeled as simple `malloc` call.
Following constructs are still not working properly:
- array new `new [size_expr]`
- run initializer attached to `new` (such as `new int(5)`)
- `delete[]`
Summary:
When detecting a resource leak, Infer used to raise an Leak exception and then prevent the specs to be computed for the paths containing a leak. This diff prevents resource leak to stop the analysis.
Summary:
1. Unify the code now that MemberExpr has more information available and it can be shared with ObjCIvarRefExpr
2. Use type from decl_ref instead of expression type. For methods, expression type is useless (`<bound something something`>). For fields it should be the same
Summary:
No longer swallow compilation failures for javac. Before this diff, the compilation failures where raised:
> infer -- javac Test.java
Test.java:5: error: ';' expected
static String str = "Hello"
^
1 error
but the exit code was incorrect:
> echo $?
0
With this diff, the failing command is printed in standard error:
> infer -- javac Test.java
Javac compilation error with:
['javac', '-g', 'Test.java', '-J-Duser.language=en']
and the exit code is different from 0.
> echo $?
1
Summary:
Creating a persistent reference to an Activity leads to a nasty form of memory leaks (see http://android-developers.blogspot.com/2009/01/avoiding-memory-leaks.html, https://corner.squareup.com/2015/05/leak-canary.html). There are many ways to create a bad persistent reference to an Activity, but the most obvious one is via a static field.
This diff implements a very simple form of Activity leak checking by inspecting postconditions to see if a subtype of Activity is reachable from a static field (and it reports an error if so). This is a very simple and limited form of leak checking that does not understand the Android lifecycle at all. In particular, if one creates a persistent reference to an Activity and then nulls it out in `onDestroy` (a reasonably common pattern), this approach will wrongly report a bug.
Summary:
The methods in objc can have the same name in the same class, but one be instance and the other class,
so that we need to take the instance flag into account when defining unique names for ObjC methods.
Summary:
This is mostly useful to authors of annotation processors and
`javac`-based static analysis tools. The nullable return models
cover these packages pretty comprehensively (with the exception
of the various visitor classes). The non-nullable parameter models
are mostly there to help make the nullable return models more useful,
as some codepaths will pass a nullable object to one of the utility
classes but never actually invoke a method on the nullable object itself.
Summary:
While `-results_dir` is still the main place to look for specs files and to write reports,
it's necessary to load specs from multiple folders because some build tools that run Infer with a target-level granularity may need to move specs files around in order to get complete reports, whereas with this change they just need to keep track of the `specs` folders generated for each target, and pass them through `-lib dir1 -lib dir2 ... -lib dirN`
Summary:
Buck is creating javac compilation commands with arguments of the form:
-Opt={"list": ["pif", "paf", "pouf"]}
While converting command lines from bash to python, these option gets split into
['-Opt={"list":', '["pif",', '"paf",', '"pouf"]}']
instead of:
['-Opt={"list": ["pif", "paf", "pouf"]}']
which create the compilation to fail when running Infer even though the original files are compiling correctly.
Summary:
The symbolic execution was not stopping in case an unitialized dangling pointer was
passed to a function and then dereferenced inside the callee.
What would happen is that a wrong footprint would be added to the unititialized pointer
at the end of the function call in the caller proposition.
This checks that if we do:
frame * new_footprint
checks that we do not add heap predicates to the frame into uninitialized local variables.
If we can identify the variable then we raise a danglind pointer dereference. If instead
we cannot give a good explanation we give an internal error.
The latter case should be temporary. We should find a general way to raise dangling pointer
deref instead of the internal error.
I also fixed the model of getc that was the way I found the problem.
Sam Blackshear
Rohan Jacob-Rao
Andrzej Kotulski
Jules Villard
martinoluca
jrm
Dulma Rodriguez
Jonathan Keljo
Dino Distefano