Summary:
- inferbo introduced a dependency to extlib. When building Java analyzers, this
is implicitly pulled in by javalib, but it's missing when building only the
clang analyzers. Add `extlib` to the packages we build against.
- infer.ml and Javac.ml depend on Javalib, but it's easy to push down the code
that needs it to `jMain.ml` so that we can build without javalib for the
clang-only case.
- jMain.mli had 2 copies: one in java/ and one in java_stubs/. Make one a symlink to the other.
Reviewed By: jeremydubreil
Differential Revision: D4566581
fbshipit-source-id: 214a4eb
Summary:
Sevel auxiliary files made it to the output directory of the analysis of individual targets when analyzing Java projects build with Buck. However, these files are then taken into account= to compute the target rule key and then to decide whether to analyze the dependent targets. Since these auxiliary files were containing time sentive information, every cach miss on a given target would then invalitate the cache entries for all the dependent targets.
This diff cleans up the output directory to only keep the specs files, the `global.tenv` and the `report.json` files which are the only artifacts needed to analyze the dependent targets
This diff makes a minimal number of changes to see how it behaves in prod, but I intend to refoctor this more when continuing to add support for running Infer with genrules
Reviewed By: sblackshear
Differential Revision: D4562615
fbshipit-source-id: 4628420
Summary:
It seems that the `close()` method that should normally be called on an object `obj` of type `java.io.Closeable` is sometimes called on `obj` of type `java.lang.Object`. It did not fully understand in which case this happens but it could be coming from a bug in Sawja since the type of `obj` in the bytecode is correct, but the Sawja reciever expression given to the Java frontend has the type `java.lang.Object`.
In any case, it does not hurt to always consider that `obj.close()` will replace the `FILE` attribute on `obj` by a `MEM` attribute.
Reviewed By: sblackshear
Differential Revision: D4540627
fbshipit-source-id: 71f9c95
Summary:
Remove the remaining uses of polymorphic equality `=`.
In case of basic types, this is replaced by String.equal or Int.equal.
In case of `= []`, this is replaced by `List.is_empty`.
In case of `= None`, this is replaced by `is_none`.
In case of a datatype definition such as `type a = A | B`,
a `compare_a` function is defined by adding `type a = A | B [@deriving compare]`
and a `equal_a` function is defined as `let equal_a = [%compare.equal : a]`.
In case of comparison with a polymorphic variant `= `Yes`, the equality
defined in `PVariant.(=)` is used. Typically, `open! Pvariant` is added
at the beginning of the file to cover all the uses.
Reviewed By: jberdine
Differential Revision: D4456129
fbshipit-source-id: f31c433
Summary: The previous version of the code could fail if the class filename would contain "class" as part of the name and not be a valid class filename ending with the `.class` suffix
Reviewed By: sblackshear
Differential Revision: D4451859
fbshipit-source-id: 874832a
Summary:
Races on volatile fields are less concerning than races on non-volatile fields because at least the read/write won't result in garbage.
For now, let's de-prioritize these writes by ignoring them.
Reviewed By: peterogithub
Differential Revision: D4434023
fbshipit-source-id: 05043ba
Summary:
Force clients to specify the path relative to which relative paths
should be made absolute.
Reviewed By: akotulski
Differential Revision: D4370262
fbshipit-source-id: 36a2807
Summary: Adding the information that a procedure has been modelled as part of the attributes, during the translation, instead of getting this information from where is the summary loaded from. This is more consistent with the use of the attributes in other parts of the analysis, but is also useful in the context of the lazy dynamic dispatch algorithm where the procedures, including the models, are cloned and reanalyzed with more specialized parameters. The information about whether a procedure is a model must persist when cloning the procedures.
Reviewed By: sblackshear
Differential Revision: D4356892
fbshipit-source-id: 40ff5ca
Summary:
SuppressWarnings annotations are hardly used and add considerable
complexity due to requiring recompilation with an annotation processor.
Reviewed By: jvillard
Differential Revision: D4312193
fbshipit-source-id: c4fc07e
Summary:
<ugly shameful hack>
Temporarily redirect stderr to /dev/null before calling `Javalib.get_class` so
as to avoid getting spammed with "Warning: unexpected attribute: Code" messages
when parsing Java files.
</ugly shameful hack>
I suspect that now that Javalib handles Java 8 this issue is more prevalent. An
issue/PR should be sent to Javalib too so that it's fixed upstream and we can
eventually remove the hack (t15039096).
Reviewed By: jberdine
Differential Revision: D4319466
fbshipit-source-id: af855ba
Summary:
Use In_channel and Out_channel operations instead of those in Pervasives. Don't
use physical equality on values that aren't heap-allocated since it doesn't help
the compiler generate faster code and the semantics is unspecified. Also use
phys_equal for physical equality.
Reviewed By: sblackshear
Differential Revision: D4232459
fbshipit-source-id: 36fcfa8
Summary:
Utils contains definitions intended to be in the global namespace for
all of the infer code-base, as well as pretty-printing functions, and
assorted utility functions mostly for dealing with files and processes.
This diff changes the module opened into the global namespace to
IStd (Std conflict with extlib), and moves the pretty-printing
definitions from Utils to Pp.
Reviewed By: jvillard
Differential Revision: D4232457
fbshipit-source-id: 1e070e0
Summary:
Functions related to source files were already namespaced by `source_file_` prefix. Make separate module for them.
In high level it replaces all `source_file_` with `SourceFile.` and then fixes all remaining compilation errors
Reviewed By: jvillard
Differential Revision: D4299053
fbshipit-source-id: 20b1d39
Summary:
This is legacy code that dates back from when we needed the fields in the models to match exactly the fields in the classes being modeled. We no longer need to this. Besides, it seems that this `android.jar` stopped being part of the release for a while. So this change will not affect the results in prod
I check in details the difference on the code of Guava and it seems to remove (weird) false positives only.
Reviewed By: sblackshear
Differential Revision: D4242444
fbshipit-source-id: 84dd782
Summary:
`DB.source_file_to_string` is very easy to misuse and it shouldn't even exist.
In preparation for that day, replace most of `source_file_to_string` with `source_file_pp`
Reviewed By: jvillard
Differential Revision: D4258390
fbshipit-source-id: 447cf5a
Summary: Add some basic command line API to run Infer using Buck genrules. Remains to fix issues with absolute vs relative paths and to see how to create these genrules on the fly for a given java or android library.
Reviewed By: sblackshear
Differential Revision: D4245622
fbshipit-source-id: 1cda4ee
Summary:
1. Always store cpp model source_file with relative path. This will make them cache friendly independent of infer location
2. Distinguish between "relative to project root" and "relative to infer models src"
3. Unify `source_file_from_path` used by java and C frontends into one function. There are no improvements to that logic yet
4. Move `is_cpp_model_file` to use `source_file` instead of `filename`
Reviewed By: jberdine
Differential Revision: D4204548
fbshipit-source-id: 6e21771
Summary:
Using DB.source_file_to_string may return relative path which may or may not be relative to current location.
I went through all calls to `DB.source_file_to_string` and fixed ones that used that output to open files
Reviewed By: jeremydubreil
Differential Revision: D4205407
fbshipit-source-id: b285b7e
Summary:
Translate local variable names using the bytecode directly instead of JBir. The bytecode has more precise type information.
We still need to declare the temporary variables intruduced by Sawja until we can base the translation directly on the bytecode.
Reviewed By: sblackshear
Differential Revision: D4185309
fbshipit-source-id: 81904a0
Summary: Infer starts from bytecode generated by the compilation commands, so there isn't much need to check if the bytecode is compliant or not.
Reviewed By: sblackshear
Differential Revision: D4179218
fbshipit-source-id: 2f27148
Summary: If seems that we were dropping succesful loaded classes for no reason
Reviewed By: sblackshear
Differential Revision: D4178079
fbshipit-source-id: 827c0b9
Summary:
Our patch to Javalib has been accepted, so we can parse programs with invokedynamic!
invokedynamic still crashes Sawja, but I have worked around this by replacing all invokedynamic's with invokestatic's before passing them to Sawja.
This means we can handle everything about invokedynamic except calling the correct function (I call a dummy function with the correct signature for now).
We can try to actually call the right method in the future.
Reviewed By: jvillard
Differential Revision: D4160384
fbshipit-source-id: a8ef4e1
Summary: Mark native methods as defined so that the analysis generates a summary for those methods. When analyzing Java projects compiled with Buck, the summaries for the dependencies methods of are retrieved from the classpath. In this case, having access to the summary is useful to access the attributes of a callee when the callee is part of a, previously analyzed, Buck target.
Reviewed By: sblackshear
Differential Revision: D4141362
fbshipit-source-id: 75888c8
Summary:
Only the python code passes --models, always does so, and only ever
passes Config.models_jar.
Reviewed By: jeremydubreil
Differential Revision: D4151094
fbshipit-source-id: 8f21c03
Summary:
Location.nLOC was introducing a lot of complexity for little benefit (and edge cases were wrong anyway).
We can restore it in some simplified way if we find that we need it
Reviewed By: jeremydubreil
Differential Revision: D4139868
fbshipit-source-id: 4f8e033
Summary: Having only place where the code runs the transformation of the Java bytecode into the JBir reporesentation allows to more easily start manipulating the JBir representation and the bytecode together and progressively move the translation based on bytecode instead of JBir.
Reviewed By: sblackshear
Differential Revision: D4137576
fbshipit-source-id: c483528
Jules Villard
Jeremy Dubreil
Cristiano Calcagno
Sam Blackshear
Josh Berdine
Andrzej Kotulski