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.
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.
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.
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
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
cleanup of how JDT analysis engines work, to make using the JDT front end more modular
bug foxes to JavaScript handling, most notably fixing scoping of functions
git-svn-id: https://wala.svn.sourceforge.net/svnroot/wala/trunk@4123 f5eafffb-2e1d-0410-98e4-8ec43c5233c4
1) adopted the code from Rational for HTML handling
i) extended it to integrate better source mapping into IR
ii) integrated fixes from the old html processing to collect more info on forms
iii) added some copyright comments
2) updated version of jericho
3) added support for nu.validator for html5
4) added script to fetch html parser jars, and removed binary jar
git-svn-id: https://wala.svn.sourceforge.net/svnroot/wala/trunk@4095 f5eafffb-2e1d-0410-98e4-8ec43c5233c4
When someone writes:
MyFunction.prototype.myMethod = ...
we want "myMethod" to be accessible only for objects of type "MyFunction".
- Change how generated ctors look like - now they have a private prototype object into which methods can be added
- Change the PropertyReadExpander to have a different handling when reading the "prototype" field, avoid performing a loop on the prototype chain, so that the points to set of fetched field will be accurate (and allow us to set only the fields of it)
git-svn-id: https://wala.svn.sourceforge.net/svnroot/wala/trunk@3959 f5eafffb-2e1d-0410-98e4-8ec43c5233c4
Manu Sridharan
Ben Liblit
Julian Dolby
Manu Sridharan
Julian Dolby
Manu Sridharan
Marcel Bruch
dolby-oss
msridhar1
sjfink
yinnon_haviv