6087b73cee
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.
|
||
|---|---|---|
| .. | ||
| AndroidAnalysisContext.java | ||
| CGAnalysisContext.java | ||
| CLISCanDroidOptions.java | ||
| DexDotUtil.java | ||
| EmptyProgressMonitor.java | ||
| EntryPoints.java | ||
| IEntryPointSpecifier.java | ||
| ISCanDroidOptions.java | ||
| LoaderUtils.java | ||
| ThrowingSSAInstructionVisitor.java | ||