These are all problems that Eclipse can detect, but that it detects no
instances of right now. Treating these as warnings instead of errors
should help prevent us from slipping backward in the future.
This is the first time I can ever remember explicitly casting to
`Object`. Such a cast might seem useless, and certainly it is
statically known to always succeed. However, it is here for good
reason. Without the cast, we end up making a `Pair<Object, ?>` but
what we really want is a `Pair<Object, Object>`.
Each of these required careful consideration of what the original
developer *intended* as distinguished from what the developer's code
actually *does*. I believe I got each one right, and WALA's
regression tests agree. A second opinion by a core WALA developer
would be welcome, though.
Previously we had 242 such warnings. That large number suggests that
the WALA developers consider this to be an acceptable coding style.
If that's so, then it's better to hide these warnings rather than keep
them around as a perpetual distraction.
In "com.ibm.wala.cast.test", the "cbuild.sh" script is gone entirely.
Instead, "pom.xml" directs Maven to run "make" directly. We still
have a "Makefile.configuration" file in this project, but this file is
now independent of where WALA is being built and of where Java is
installed.
In "com.ibm.wala.cast", a small "cbuild.sh" remains, to do some
special processing involving Visual Studio variables under Windows.
When not building under Windows, "cbuild.sh" now simply runs "make".
It may well be possible to hoist the special Windows stuff up into
this subproject's "pom.xml", or to change that "pom.xml" to run
"cbuild.sh" only when on Windows, and to run "make" directly
otherwise. I don't know "pom.xml" stuff very well, though. We still
have a "Makefile.configuration" file in this project, but this file is
now independent of where WALA is being built and of where Java is
installed.
The changes I've made in both "Makefile.configuration" files use GNU
make extensions. I assume that's safe because "Makefile.definitions"
already relies on GNU make.
In general, these diagnostics are now errors in projects for which all
such warnings have been fixed. There are three unfixed warnings in
two projects, so this diagnostic remains a warning (not an error) in
those projects.
There are also many places where rwa-types-usage warnings have been
locally suppressed using @SuppressWarnings annotations. I haven't
systematically revisited those to see if any can be fixed properly.
So for those projects this diagnostic must also remain a warning (not
an error), since @SuppressWarnings does not work on things Eclipse is
configured to treat as errors.
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.
There are two such diagnostics: one for collection methods and one for
equals(). See
<https://www.eclipse.org/eclipse/news/4.7/jdt.php#unlikely-argument-types>
for more information about these two new diagnostics.
For each of these diagnostics, I've set the severity level to
"warning" in projects that have some instances of the suspicious code,
or to "error" in projects that have no instances of the suspicious
code.
Julian Dolby
Julian Dolby
Ben Liblit
Manu Sridharan
Manu Sridharan