* 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
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.
1) The visitors nested in the SSAPropagationCallGraph have become static classes so that they can be reused in a delegation pattern for the cross-language call graph builder.
2) The ClassHierarchy is now encapsulated behind an IClassHierarchy interface to allow for a CrossLanguageClassHierarchy that delegates to a set of child hierarchies, one for each language. The internals of the ClassHierarchy are almost entirely unchanged
3) There is now a new Language interface in com.ibm.wala.classLoader, and all IClassLoader objects have to know what language they load for. This language object now encapsulates a few language-specific options that were previously hacked into the AnalysisOptions object.
git-svn-id: https://wala.svn.sourceforge.net/svnroot/wala/trunk@1212 f5eafffb-2e1d-0410-98e4-8ec43c5233c4
Erik Derr
Ben Liblit
Julian Dolby
Manu Sridharan
sjfink
dolby-oss