Summary: Infer cannot tell if a procdesc has changed across procedure runs. If we want procedure-level incrementality, it has to know how to compute this information. This diff implements this capability by comparing a procdesc to an existing one before it is saved to disk, and marking the new one as unchanged if applicable.
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.
Rohan Jacob-Rao
Sam Blackshear
Andrzej Kotulski
Jules Villard
martinoluca
jrm
Dulma Rodriguez
Jonathan Keljo