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.
This gives the WALA maintainers the option of doing future 1.4.5+
releases from of a pre-Gradle branch if these merged Gradle changes
turn out to be more disruptive than expected.
If multiple tests both write to "/tmp/cg.txt" (for example), then
these tests cannot safely run concurrently. That never used to be a
problem with Maven, since our Maven tests were all strictly sequential
anyway. But parallelized testing using Gradle requires that we do
better. Fortunately, Java has perfectly reasonable APIs for
generating uniquely-named temporary files and directories.
This fixes the last of our Javadoc warnings without creating a
circular dependency between ":com.ibm.wala.cast:javadoc" and
":com.ibm.wala.cast.js:javadoc". Fixes#4, wherein more details about
this tricky dependency challenge can be found.
These settings files currently are generated with an initial timestamp
comment line, which is not something we'd want to track in version
control. Fortunately, the contents of these files are entirely
mundane, so there should be no problem with having Buildship generate
them anew each time a developer imports WALA into Eclipse as an
existing Gradle project.
Apparently Buildship generates these when one uses Import -> Existing
Gradle Project:
<https://discuss.gradle.org/t/buildship-eclipse-plug-in-multiproject-builds/24030/5>.
We can use the Gradle "eclipse" plugin if customizations are
necessary, but my impression is that the intent is to treat ".project"
and ".classpath" as generated files, not sources to be tracked in
source control.
I was confused about the differences among:
srcDir 'foo'
srcDirs ['foo']
srcDirs = ['foo']
As it turns out, the first two append to the set of source
directories, while the last replaces this set entirely. I generally
want replacement, since WALA's current directory layout never matches
Gradle's assumed defaults.
This gives the WALA maintainers the option of doing future 1.4.5+
releases from of a pre-Gradle branch if these merged Gradle changes
turn out to be more disruptive than expected.
If multiple tests both write to "/tmp/cg.txt" (for example), then
these tests cannot safely run concurrently. That never used to be a
problem with Maven, since our Maven tests were all strictly sequential
anyway. But parallelized testing using Gradle requires that we do
better. Fortunately, Java has perfectly reasonable APIs for
generating uniquely-named temporary files and directories.
This fixes the last of our Javadoc warnings without creating a
circular dependency between ":com.ibm.wala.cast:javadoc" and
":com.ibm.wala.cast.js:javadoc". Fixes#4, wherein more details about
this tricky dependency challenge can be found.
These settings files currently are generated with an initial timestamp
comment line, which is not something we'd want to track in version
control. Fortunately, the contents of these files are entirely
mundane, so there should be no problem with having Buildship generate
them anew each time a developer imports WALA into Eclipse as an
existing Gradle project.
Apparently Buildship generates these when one uses Import -> Existing
Gradle Project:
<https://discuss.gradle.org/t/buildship-eclipse-plug-in-multiproject-builds/24030/5>.
We can use the Gradle "eclipse" plugin if customizations are
necessary, but my impression is that the intent is to treat ".project"
and ".classpath" as generated files, not sources to be tracked in
source control.
I was confused about the differences among:
srcDir 'foo'
srcDirs ['foo']
srcDirs = ['foo']
As it turns out, the first two append to the set of source
directories, while the last replaces this set entirely. I generally
want replacement, since WALA's current directory layout never matches
Gradle's assumed defaults.
Achim D. Brucker
Julian Dolby
Erik Derr
Sifis Lagouvardos
Manu Sridharan
Ben Liblit
Sungho Lee