Closed zsiegel closed 9 years ago
Yeah, that would be much appreciated - one example of a popular library using this class name scheme during automatic code generation is Dagger which is indeed widely used. Can't use infer until this issue is solved. :crying_cat_face:
+1
Exact same problem here. The Infer output says you can add abortOnError false
to lintOptions
, but I would rather this just not cause an error in the first place.
@zsiegel Which library is doing it for you? I personally am not using Dagger
, but perhaps Butterknife
?
Yea butter knife caused this problem for me personally.
Thanks for the report! This is due to a problem in the javalib library we use to parse Java bytecode. We are working on getting it fixed upstream.
+1, looking forward to the fix for this!
+1
+1
+1 for Butterknife, would also love to use Dagger and I believe the Dagger2 generated classes have similar naming to Butterknife so potentially same issue here. Possibly a way to exclude generated classes?
Yes, we will just skip the classes with the name containing $$ for now, while we are trying to fix the library used to parse the bytecode.
I met the same problem when i used ButterKnife library in my project. Look forward the new feature!:)
Here is my log.
Fatal error: exception Invalid_argument("Error : com.packagename.HomeActivity$$InjectAdapter is not a valid name for a class")
[ERROR] Failure during frontend, original command was
[u'inferJ', u'-g', u'-a', 'capture', u'javac', '-source', '1.7', '-target', '1.7', '-d'{bunch project jars}]
Traceback (most recent call last):
File "/Library/infer-osx-v0.1.0/infer/infer/bin/infer", line 142, in <module>
main()
File "/Library/infer-osx-v0.1.0/infer/infer/bin/infer", line 119, in main
capture_exitcode = imported_module.gen_instance(args, cmd).capture()
File "/Library/infer-osx-v0.1.0/infer/infer/bin/../lib/capture/gradle.py", line 42, in capture
return util.run_commands(cmds)
File "/Library/infer-osx-v0.1.0/infer/infer/bin/../lib/capture/util.py", line 34, in run_commands
if not cmd.start():
File "/Library/infer-osx-v0.1.0/infer/infer/bin/inferlib.py", line 632, in start
if self.capture() == os.EX_OK:
File "/Library/infer-osx-v0.1.0/infer/infer/bin/inferlib.py", line 400, in capture
return self.run_infer_frontend()
File "/Library/infer-osx-v0.1.0/infer/infer/bin/inferlib.py", line 391, in run_infer_frontend
self.args.analyzer
File "/Library/infer-osx-v0.1.0/infer/infer/bin/inferlib.py", line 318, in run_command
raise e
subprocess.CalledProcessError: Command '[u'/Library/infer-osx-v0.1.0/infer/infer/bin/InferJava', u'-results_dir', u'/Users/user/GitHub/Android-app/infer-out', u'-verbose_out', '/var/folders/68/4pkjv9fd743040h3dmj98kbm0000gn/T/javac_KjBTQT.out', u'-models', u'/Library/infer-osx-v0.1.0/infer/infer/bin/../lib/java/models.jar', u'-no-static_final']' returned non-zero exit status 2
@oshamahue: did you use the Infer binaries or did you compiled Infer from sources ?
@jeremydubreil I used the binaries. I added infer-osx-v0.1.0/infer/infer/bin as a path and used it from there.
+1 ... a fix for Butterknife (and Dagger, if there's a problem as well) would be highly appreciated :dancer: :)
This issue has been sidestepped by 4526ada822d01728c4ac0ac30fd2f9a2aa115c0f, which stops Infer from crashing when it encounters $$ classnames (though it won't analyze these classes; we are working on that). However, you have to build Infer from source for this to work; we haven't released new binaries with the fix yet.
@sblackshear can you release a new version with this fix? Do you have planned release schedules?
Hi, we made a new release today that contains the fix. You could try it out. We are planning to do releases regularly.
Any idea when the upstream fix in javelib will get done? For those of us using Dagger, not analyzing the Dagger injected classes basically means that very little in our Android projects get analyzed. All our "services" / "business logic" classes are injected.
Hey @dmorehouse, As dulmarod mentioned above, they pushed a new build which fixes this issue. Download the latest binaries and try again.
@plowman The fix right now is just sidestepping the $$
classes and not analyzing them.
This problem should be fixed soon and will likely make it to the next release of Infer in the next few days. Stay tuned!
Aha, that makes more sense. Thanks @mattblang.
This has been fixed in the latest release.
Many annotation libraries generate class names with $$ in them. It would be great if that could be supported. Currently
Infer
spits out the following...