the declared target of the call site. This is needed to make sure
forName targets loaded with the Application loader get resolved to point
to the real metod reference for forName.
this issue actually manifested itself in the Kawa Chess program, and so
I have added an assertion to make sure this resolution is done properly.
Fixes inconsistent behavior of the exclusions argument.
Depending on the androidLib argument, setting exclusions to null
is either fine or raises and exception.
This patch makes exclusions truely optional for any case
when null is passed.
* Impl of IMethod isSynthetic and isWalaSynthetic
So far IMethod.isSynthetic referred to WALA-generated helper functions
and there was no equivalent to check whether an IMethod is synthetic in
terms of compiler-generated.
To make naming consistent this patch first renames the isSynthetic to
isWalaSynthetic to clearly indicate that a given IMethod was generated
by WALA. Then, we re-introduce isSynthetic that from now on checks
whether an IMethod is synthetic/compiler-generated (referring to the
synthetic flag in bytecode)
* Implementation of IClass.isSynthetic
Complementary to IMethod.isSynthetic, this method checks whether
an IClass is compiler-generated.
* updated JavaDoc
* Fixes IllegalStateException
Reverts refactored code with try-with-resource back to potentially
leaking implementation. The refactored code threw an exception since
JarFileModule does not implement the AutoClosable interface. Further,
removed the printStackTrace() call, as this is not an exceptional case
but intended control-flow in case DexFileModule creation fails.
* Downgrade JarFile leak diagnostic from warning to error
This is consistent with how we are treating potential JarFile leaks in
other WALA components. WALA issue #236 already notes that these
should be cleaned up eventually, although doing so will not be easy.
These specific test resources are already included in the "testArchives"
configuration of the "com.ibm.wala.core.tests" subproject, upon which
the "com.ibm.wala.dalvik.test" tests already depend. So there's no need
to also copy these resources into the "com.ibm.wala.dalvik.test" test
resources area as well.
Previously I hadn't realized that Gradle's "java" plugin would generate
default "cleanTest" tasks for us. By defining my own "cleanTest" tasks
we were replacing the generated ones, but what we really wanted to do
was augment them with additional files to delete.
Achim D. Brucker
Julian Dolby
Erik Derr
Sifis Lagouvardos
Sungho Lee
Bryan Tam
Manu Sridharan
Ben Liblit