Effectively these two checks could only be false if the instance being
tested were null. So we replace the instanceof checks with null
checks. Sometimes that, in turn, makes other surrounding code
simpler. In the case of ApplicationLoaderFilter.test, for example,
a whole conditional case ("o instanceof LocalPointerKey") becomes
statically impossible. That seems a bit strange to me, but that's
what the code was effectively doing.
In the cases addressed here, the caught exception was being "handled"
by throwing some new exception. Instead of discarding the old
exception, pass it to the new exception's constructor to indicate the
original cause of the newly-created exception. This practice, called
"exception chaining", can often be useful in debugging.
This fixes the remaining 34 Eclipse "Resource '...' should be managed
by try-with-resource" warnings that were still left after the previous
commit.
Unlike the fixes in that previous commit, the changes here are *not*
plugging potential resource leaks. However, in many cases that is
simply because the code before the close() call cannot currently throw
exceptions. If exceptions became possible in the future, leaks could
result. Using try-with-resource preemptively avoids that.
Furthermore, in code that was already dealing with exceptions, the
try-with-resource style is usually considerably simpler.
This fixes 33 out of 37 Eclipse "Potential resource leak: '...' may
not be closed" warnings. It also fixes 3 out of 37 Eclipse "Resource
'...' should be managed by try-with-resource" warnings, although that
was not the main focus of this effort.
The remaining 4 warnings about potential resource leaks all involve a
leaked JarFile instance that is passed to a JarFileModule constructor
call. JarFileModile never attempts to close its underlying JarFile;
this code is written as though JarFile cleanup were the caller's
responsibility. However, the JarFile often cannot be closed by the
code that creates the JarFileModule either, since the JarFile needs to
remain open while the JarFileModule is in use, and some of these
JarFileModules stay around beyond the lifetime of the code that
created them. Truly fixing this would essentially require making
JarFileModule implement Closeable, which in turn would probably
require that Module implement Closeable, which in turn would require
changes to lots of code that deals with Module instances to arrange
for them to be properly closed. That's more invasive than I'm
prepared to take on right now.
Instead, rely on Java's ability to infer type parameters in many
contexts. This removes 665 Eclipse warnings.
Note: a few of these changes are to files under "test" subdirectories.
Presumably those are files that serve as test inputs rather than being
part of WALA code proper. As far as I can tell, these changes do not
break any WALA tests. But if any of those tests were specifically
intended to exercise WALA on code with non-inferred generic type
parameters, then I really should be leaving those alone.
Previously, the various Eclipse projects' Java configurations used
mixtures of 1.6, 1.7, and 1.8. Many were internally inconsistent,
such as requiring 1.7 in "MANIFEST.MF" but 1.6 in the Eclipse JDT
build preferences. The Travis-CI configuration tests against both 1.7
and 1.8, but does not test against 1.6.
Across all projects, the most common version was 1.7. So I'm going to
assume that 1.7 is the intended build target. This commit makes 1.7
the selected version nearly everywhere.
"com.ibm.wala.core.testdata" is the one exception. This specific
project uses a few features only found in 1.8, such as lambda
expressions. Previously, "com.ibm.wala.core.testdata" used 1.7 in
some aspects of its configuration but 1.8 in others. Now it
consistently targets 1.8. I wish this one project didn't need to be
inconsistent with the rest of WALA, but at least now it's consistent
with itself.
(Personally, I'd be happy to target 1.8 only. But my impression
across all of these configuration files is that the WALA developers
still want to be compatible with 1.7. If that is no longer a
requirement, let me know and I will adjust these changes accordingly
to target 1.8 only.)
This change eliminates 11 "There is no 'jre.compilation.profile' build
entry and the project has Java compliance preferences set" warnings
and 13 "The JRE container on the classpath is not a perfect match to
the 'JavaSE-1.7' execution environment" warnings. However, it also
adds 450 "Redundant specification of type arguments <...>" warnings
and 17 "Resource '...' should be managed by try-with-resource"
warnings. So this seems like a net step backward in my wish to reduce
WALA warnings. However, those new warnings concern Java 1.7 language
features that we were not previously using to good effect in projects
that targeted 1.6. If we all agree that we can now target 1.7
instead, then we can use these helpful features as the newly-added
warnings suggest. So I call that a step in the right direction.
Some source files here definitely use Hamcrest, so listing it as a
dependency seems reasonable. What I find confusing is the inconsistency
among my Eclipse installations. On some of my various machines, Eclipse
reports an error if this dependency is not listed. On others, Eclipse
finds the required jar and reports no error, even if this dependency is
not listed. I don't know why the latter works, or why the inconsistency
exists at all. Eclipse is a complex, subtle beast. What I can say is
that this change fixes the error for my Eclipses that were reporting an
error, and does not introduce any new errors for my Eclipses that were
already happy before this change.
We actually know the full grammar for these files: it is documented at
<http://help.eclipse.org/kepler/index.jsp?topic=%2Forg.eclipse.platform.doc.isv%2Freference%2Fmisc%2Fplugin_manifest.html>.
We ought to be able to extract that DTD into a file and give each
"plugin.xml" a "<!DOCTYPE plugin SYSTEM ...>" declaration referencing
it. Unfortunately, that leads to a new warning: "External entity
resolution is not supported by PDE." So a stub declaration is the
best we can do. Fortunately, Eclipse's structured editor seems to
preserve these once we add them by hand.
I think the "target/p2artifacts.xml" and "target/p2content.xml" files
are generated by Maven. They are well-formed XML but Eclipse's XML
validator legitimately warns that they lack grammar constraints.
Since we're not maintaining the tool that creates these files, we are
not in a position to do anything about that. Therefore, we may as
well exclude these from validation entirely. That way we can
more-clearly recognize warnings that we *can* do something about.
Ant "build.xml" files don't have a standard DTD or XML Schema; the
contents are simply too flexible for that. But we can at least
give each a stub DOCTYPE declaration. That's enough to satisfy
Eclipse's XML validator, which otherwise complains that these files
lack grammar constraints.
As created by Tycho Surefire, these files are XML documents without
DTD or XML Schema declarations. The XML validator warns about this
omission. However, Surefire is not a WALA component. We are not in a
suitable position to change it to include XML schema or DTD
declarations in the XML files it generates. Better, then, to ignore
this benign problem so we can focus on warnings that we can act on
directly.
The contents of @author go straight into HTML, just like most other
Javadoc material. So if you want to have a "<foo@bar.com>" e-mail
address as part of the author information, the angle brackets must be
escaped. Here I've opted to do that using "{@code <foo@bar.com>}",
which has some additional styling effects that seem appropriate for
e-mail addresses. We could also have used "<foo@bar.com>" for
escaping without code styling.
Eclipse validation warns about invalid HTML content in all
Maven-generated "target/site/dependency-convergence.html" files. The
warnings are legitimate: these HTML files are indeed invalid.
However, we don't maintain the tool that generates these files, so we
are not in a position to fix them. Better, therefore, to suppress
these warnings so that we can notice and fix other problems over which
we do have control.
In general, the WALA code base is not really ready for nullness
checking. It would be nice if we got there some day, but I'm not
planning to take that on now or any time soon. Until then, it's not
useful to warn about missing @NonNullByDefault declarations on WALA
packages.
See also older commit 7b6811b.
Eclipse Mars Service Release 2 finds 45 potential null pointer accesses
across WALA's various Eclipse projects. Eclipse ignores these by
default, but any individual user may have changed their personal Eclipse
configuration to treat them as warnings or errors. Thus, some people
will find that the code builds while others find that it fails. Better
to explicitly use a known-good configuration.
In the long run someone should inspect these cases one-by-one and fix
them where appropriate. But that is probably better managed as part of a
larger effort to tidy up nulls in WALA. I'm not planning to take that on
now or any time soon, though, so this is a better setup for now.
PrunedCFG had been changed to always include an entry and exit node.
The logic for detecting an "empty" ExceptionPrunedCFG inside the PDG
construction code had not been updated appropriately.
a) serializable added for use by Android services
b) test classes refactored to allow Android variants to use JUnit 3
2) shrike instrumentation now uses java.lang.instrument
a) refactoring
b) online variants of call graph tracing
now, for me, code works using e44 with maven
dalvik tests refactored for mobile version with android dev tools
IDE tests Eclipse metadata fixed to make e44 work for me
new android entrypoint to fix failure in new droidbench tests
com.ibm.wala.cast.js.rhino.test/harness-src/com/ibm/wala/cast/js/test/TestPrototypeCallGraphShapeRhino.java
com.ibm.wala.cast.js.test/harness-src/com/ibm/wala/cast/js/test/TestPrototypeCallGraphShape.java
com.ibm.wala.cast.js.test.data/examples-src/pages/prototype.html
work (not yet finished) on fixes to property accesses for JavaScript:
com.ibm.wala.cast/source/java/com/ibm/wala/cast/ipa/callgraph/AstSSAPropagationCallGraphBuilder.java
com.ibm.wala.cast.java/src/com/ibm/wala/cast/java/ipa/callgraph/AstJavaSSAPropagationCallGraphBuilder.java
com.ibm.wala.cast.js/source/com/ibm/wala/cast/js/ipa/callgraph/JSSSAPropagationCallGraphBuilder.java
currently unused tests to remind me to fix bugs:
com.ibm.wala.cast.js.test/harness-src/com/ibm/wala/cast/js/test/TestSimpleCallGraphShape.java
com.ibm.wala.cast.js.test.data/examples-src/tests/loops.js
com.ibm.wala.cast.js.test.data/examples-src/tests/primitive_strings.js
fixes to exception handler code generation in JavaScript:
com.ibm.wala.cast.js.rhino/source/com/ibm/wala/cast/js/translator/RhinoToAstTranslator.java
com.ibm.wala.cast.js.test.data/examples-src/tests/try.js
com.ibm.wala.cast.js.test/harness-src/com/ibm/wala/cast/js/test/TestSimpleCallGraphShape.java
fixes to make the system build on both juno and luna
com.ibm.wala.cast.js.test.data/pom.xml
pom.xml
targets/e42/e42.target
targets/e44/e44.target
targets/pom.xml
com.ibm.wala.core.tests/META-INF/MANIFEST.MF
com.ibm.wala.dalvik.test/META-INF/MANIFEST.MF
com.ibm.wala.ide.jdt.test/META-INF/MANIFEST.MF
com.ibm.wala.ide.jdt/source/com/ibm/wala/cast/java/translator/jdt/FakeExceptionTypeBinding.java
com.ibm.wala.ide.jdt/source/com/ibm/wala/ide/util/JavaEclipseProjectPath.java
com.ibm.wala.ide.jsdt.tests/META-INF/MANIFEST.MF
com.ibm.wala.ide.jsdt.tests/src/com/ibm/wala/ide/jsdt/tests/AbstractJSProjectScopeTest.java
com.ibm.wala.ide/src/com/ibm/wala/ide/util/EclipseProjectPath.java
com.ibm.wala.ide/src/com/ibm/wala/ide/util/ProgressMonitorDelegate.java
beginnings of "pointer analysis" on top of field-based analysis
com.ibm.wala.cast.js/source/com/ibm/wala/cast/js/callgraph/fieldbased/flowgraph/FlowGraph.java
com.ibm.wala.cast.js/source/com/ibm/wala/cast/js/callgraph/fieldbased/flowgraph/vertices/PropVertex.java
com.ibm.wala.cast.js/source/com/ibm/wala/cast/js/callgraph/fieldbased/flowgraph/vertices/RetVertex.java
com.ibm.wala.cast.js/source/com/ibm/wala/cast/js/callgraph/fieldbased/flowgraph/vertices/VarVertex.java
com.ibm.wala.cast.js/source/com/ibm/wala/cast/js/callgraph/fieldbased/flowgraph/vertices/VertexFactory.java
com.ibm.wala.core/src/com/ibm/wala/ipa/callgraph/propagation/PointerAnalysis.java
com.ibm.wala.core/src/com/ibm/wala/ipa/callgraph/propagation/cfa/ExceptionReturnValueKey.java
fixes for crashes in correlartion tracking
com.ibm.wala.cast.js/source/com/ibm/wala/cast/js/ipa/callgraph/correlations/extraction/ClosureExtractor.java
fixes for Dalvik IR generation
com.ibm.wala.core/src/com/ibm/wala/cfg/BytecodeCFG.java
com.ibm.wala.core/src/com/ibm/wala/cfg/ShrikeCFG.java
com.ibm.wala.core/src/com/ibm/wala/ssa/SSACFG.java
com.ibm.wala.dalvik.test/source/com/ibm/wala/dalvik/drivers/APKCallGraphDriver.java
com.ibm.wala.dalvik.test/source/com/ibm/wala/dalvik/test/callGraph/JVMLDalvikComparison.java
com.ibm.wala.dalvik/src/com/ibm/wala/dalvik/classLoader/DexCFG.java
com.ibm.wala.dalvik/src/com/ibm/wala/dalvik/dex/instructions/UnaryOperation.java
com.ibm.wala.dalvik/src/com/ibm/wala/dalvik/ssa/AbstractIntRegisterMachine.java
com.ibm.wala.dalvik/src/com/ibm/wala/dalvik/ssa/DexSSABuilder.java
fixes to stack map generation when instrumenting for Java 7
com.ibm.wala.shrike/src/com/ibm/wala/shrike/cg/DynamicCallGraph.java
com.ibm.wala.shrike/src/com/ibm/wala/shrikeBT/ConstantInstruction.java
com.ibm.wala.shrike/src/com/ibm/wala/shrikeBT/analysis/Analyzer.java
com.ibm.wala.shrike/src/com/ibm/wala/shrikeBT/analysis/ClassHierarchy.java
com.ibm.wala.shrike/src/com/ibm/wala/shrikeBT/analysis/Verifier.java
com.ibm.wala.shrike/src/com/ibm/wala/shrikeBT/shrikeCT/ClassInstrumenter.java
com.ibm.wala.shrike/src/com/ibm/wala/shrikeCT/StackMapConstants.java
com.ibm.wala.shrike/src/com/ibm/wala/shrikeCT/StackMapTableReader.java
com.ibm.wala.shrike/src/com/ibm/wala/shrikeCT/StackMapTableWriter.java
analysis now understands and propagates MethodHandle objects
fixes to Shrike InvokeDynamic instruction
Former-commit-id: fb826f124423bcbca08f729cee1794fbda711d16
2) make instrumentor preserve the names of jar entries and classes as
they are input, rather than recomputing class names when writing the
output jar. This usually makes no difference, but can preserve broken
structures when the input jar file has mismatches between class names
and its entry names.
2) make instrumentor preserve the names of jar entries and classes as
they are input, rather than recomputing class names when writing the
output jar. This usually makes no difference, but can preserve broken
structures when the input jar file has mismatches between class names
and its entry names.
We put all the jar files (the testdata jar, JLex, etc.) in the root
directory now, and set up the build.properties so that these jars get
copied into the final plugin jar, making the tests work properly from
maven. We also still copy the jars into the bin/ directory, so the
Eclipse launchers still work.
These tests create FileModules for certain class / source files,
and hence assume those files are sitting in the filesystem. We
should come up with a better fix here.
- Annotation support
- Properly fix path-with-spaces bug.
- fix bug involving paths with spaces
- add a simple driver for building a call graph via a scope file
- Properly return null as default constructor of an array.
- organize imports
- better handling of missing bytecodes
- javadoc
- test fix
- small Javadoc fix
- added date-property.js
- 1) added InstanceKey.getCreation sites and its implementations 2) fixes for issues with keys representing dynamic properties i) all properties are converted to strings,
- publicize method makeClasspath(). deprecate quoteStringIfNeeded()
- organize imports
- javadoc
- renamed classes to make relationship to mod-ref analysis clearer
- add support for lexical writes
- Code to compute transitive lexical accesses of methods.
- extract some generally useful code from ModRef
- Generate proper InstanceFieldKeys for property accesses with Numbers.
- rewrite to make hardest test appear last
- fix test to properly check reachability
- add an array test that doesn't quite work
- add method to get a PointerKey for a global
- compare FieldValueDispatch objects based on CGNode as well
- Handle duplicate field names between subclass and superclass.
In some cases, class files will have non-abstract methods with no
bytecodes (e.g., stubs for compilation purposes). While such a class
file is invalid, we want to enable clients to handle such an error.
With these changes, Shrike will throw an InvalidClassFileException for
such cases, and WALA's IR construction code will throw a
WalaRuntimeException.
- basic compatibility with Java 7 (i.e., don't crash immediately)
- Added utility class for converting call graphs to JSON.
- add edgeExists CLI option to check if some edge exists in the call graph
added DFS path find that finds all paths in sequence rather than just one
moved the WalaException out of warnings subpackage
git-svn-id: https://wala.svn.sourceforge.net/svnroot/wala/trunk@4257 f5eafffb-2e1d-0410-98e4-8ec43c5233c4
1) extend ContextSelector interface to allow it to specify parameters of interest
2) extend filtering mechanism at call sites to allow CPA-style filtering when requested by contexts
3) various related fixes and extensions:
a) removed redundant code to handle dispatch for JavaScript, so now it shares the core mechanism
b) tighten types for operators that take an array of args - now the array is T[] at the cost of a few array allocation methods
c) a bit more support for empty int sets
d) void function objects
e) bug fixes for lexical scoping support, and adaptation to work with core dispatch mechanism
f) example of CPA-style sensitivity to handle nastiness in a JavaScript for(.. in ...) loop
git-svn-id: https://wala.svn.sourceforge.net/svnroot/wala/trunk@4150 f5eafffb-2e1d-0410-98e4-8ec43c5233c4
Manu Sridharan
Ben Liblit
Julian Dolby
Andrei Dan
Martin Hecker
Julian Dolby
Andreas Sewe
Manu Sridharan
steohan
Stephan Gocht
Cosmin Radoi
Juergen Graf
Michael Heilmann
ksrinivs
Manu Sridharan
Marcel Bruch
msridhar1
sjfink
dolby-oss
yinnon_haviv