facebook / infer

A static analyzer for Java, C, C++, and Objective-C
http://fbinfer.com/
MIT License
14.8k stars 2k forks source link

Any plans to support alternative JVM languages? #308

Open meoyawn opened 8 years ago

meoyawn commented 8 years ago

Kotlin is getting traction in the Android dev community Is there a way to modify infer to support analysing the JVM bytecode instead of java code?

jvillard commented 8 years ago

No immediate plan yet, but in principle there's nothing stopping Infer from starting from the bytecode, as all the heavy-lifting is done at this level already. In particular, Infer starts from the JVM bytecode to analyse Java files. Some work is needed to get rid of the dependency on the source code itself.

meoyawn commented 8 years ago

What part of the source code is responsible for that? I mean the dependency on java source files. I'd like to start playing with it, and maybe submit a patch

On 2016 март 21, дүш 17:50 Jules Villard notifications@github.com wrote:

No immediate plan yet, but in principle there's nothing stopping Infer from starting from the bytecode, as all the heavy-lifting is done at this level already. In particular, Infer starts from the JVM bytecode to analyse Java files. Some work is needed to get rid of the dependency on the source code itself.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/facebook/infer/issues/308#issuecomment-199323275

sblackshear commented 8 years ago

This would be great to have!

At a high level, what our Java frontend currently does is (for each invocation of javac, directly or by the build system): (1) Start from the verbose output of javac, which lists the classpath, list of compiled source files, and produced bytecodes) (2) Build a map from produced bytecodes to their source files (3) Use Javalib (a third-party-library) to parse the produced bytecode (4) Translate all of the Javalib-parsed bytecodes into SIL (Infer's intermediate language)

To support other JVM languages, it probably makes the most sense to add code for passing a JAR directly to step (3). Unfortunately, the logic for steps for (1) - (3) is not cleanly separated. It will likely require some refactoring before you can add the JAR option.

I would start from here, which is what does steps (2) and (3). The first step would be separating out (3) so you can pass it a JAR directly. Then, we can work on the trickier problem of replicating (2): how do you get reliable source line/variable name information starting from bytecode :).

Let me know if you have any questions!

se7en007 commented 7 years ago

Hi, I am using Play framework to build our Java application. The play framework uses SBT as build tool but all of the code written by us is in Java. I tried running infer on play compile and sbt compile, in hope that it works, but no penny.

Is there any plan of supporting it? Adding this here as scala comes under alternative JVM languages.

hasnain-db commented 2 weeks ago

hey @jvillard ! been a while :)

I wanted to follow up on this issue especially given some of the progress in https://github.com/facebook/infer/issues/985 . If I were to look into adding Scala support, are there any PRs we can follow? Do we have to start from the source (much harder) or is it possible to feed in bytecode directly to infer?

ngorogiannis commented 2 weeks ago

It should be possible to capture other JVM languages, but some tweaking is required.

infer capture 
  --genrule-mode 
  --generated-classes <jar or class files> 
  --sources <file1> ... --sources <fileN> 
  --classpath <classpath>

This should work for any JVM language provided the filtering for --sources is adapted to accept the new extensions.

Of course, there remains the issue that the resulting bytecode may use patterns not seen in the Java case, so analysers which assume those patterns may get it wrong.