In general, my approach was to try to eliminate each unused parameter
using Eclipse's "Change Method Signature" refactoring. That did not
always succeed: a parameter may be unused in some base class method,
but then be used in subclass's override of that method. In cases
where refactoring to eliminate a parameter failed, I instead annotated
the parameter with '@SuppressWarnings("unused")' to silence the
warning.
Note: this group of changes creates a significant risk of
incompatibility for third-party WALA code. Some removed parameters
change externally-visible APIs. Furthermore, these changes do not
necessarily lead to Java compilation errors. For example, suppose
third-party code subclasses a WALA class or interface, overrides a
method, but does not annotate that method as @Override. Removing a
parameter means that the third-party method no longer overrides. This
can quietly change code behavior without compile-time errors or
warnings. This is exactly why one should use @Override wherever
possible, but we cannot guarantee that third-party WALA users have
done that.
Unnecessary "throws" declarations tend to cascade. If foo() calls
bar() and bar() falsely declares that it might throw IOException, that
often leads a programmer to declare that foo() might throw IOException
as well. Fixing the bar() throws declaration then reveals that we can
fix the foo() throws declaration too. By the time we reach a fixed
point with cleaning these up, we have removed roughly 320 unnecessary
throws declarations.
In a few cases, this cleanup even lets us remove entire "try
... catch" statements where the only thing being caught was an
exception that we now statically know cannot be thrown. Nice!
In Eclipse project configurations, upgrade any future such shenanigans
from warnings to errors. Now that we've fixed this, we don't want it
coming back again.
There is a potential drawback to this change. Conceivably some public
WALA API entry point might have declared that it could throw some
exception merely to reserve the *option* of throwing that exception in
third-party code that subclasses and overrides the API entry point in
question. I have no idea whether this is a significant concern in
practice, though.
Along the way, I also converted many "for (;;)" loops into modern
"for (:)" loops. I didn't systematically look for all opportunities
to do this, though. I merely made this change where I was already
converting raw Iterator uses into modern Iterator<...> uses.
Better use of generics also allowed many casts to become statically
redundant. I have removed all such redundant casts.
Only three raw-types warnings remain after this batch of fixes. All
three involve raw uses of CallGraphBuilder. I've tried to fix these
too, but it quickly snowballs into a cascade of changes that may or
may not eventually reach a statically-type-save fixed point. I may
give these last few problem areas another go in the future. For now,
though, the hundreds of other fixes seem worth keeping even if there
are a few stragglers.
This commit may change some public APIs, but only by making weaker
type signatures stronger by replacing raw types with generic types.
For example, we may change something like "Set" into "Set<String>",
but we're not adding new arguments, changing any
underlying (post-generics-erasure) types, etc.
If a method is private, there's no risk that a subclass elsewhere
might be overriding it and depending on dynamic dispatch to choose the
right implementation. So all of these private methods can safely be
declared static without risk of regression in either WALA code or
unseen third-party code.
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.
- 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.
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
Pierlauro Sciarelli
Ben Liblit
Julian Dolby
Julian Dolby
Juergen Graf
Manu Sridharan
dolby-oss
msridhar1
egeay
rmfuhrer
sjfink