This gives the WALA maintainers the option of doing future 1.4.5+
releases from of a pre-Gradle branch if these merged Gradle changes
turn out to be more disruptive than expected.
This should give us a set of mutually-consistent jars rather than
picking up random, outdated pieces from Maven Central or wherever else
I could find them. We now also have a single, central place where we
set the Eclipse version that we're building against. Much, *much*
cleaner.
Previously Buildship removed its classpath from all of these
launchers. Now it's automatically putting that back in as soon as I
visit each launcher in Eclipse's "Run Configurations" dialog. Not
sure what's going on here, but it certainly seems more sane to me to
assume that the Buildship-computed classpath *is* needed for all of
these. I have an open question on the Gradle discussion forum to try
to understand what's going on here and how to fix it:
<https://discuss.gradle.org/t/launchers-lose-buildship-classpath-on-import-regain-it-later/25641>.
<https://github.com/liblit/WALA/issues/5> notes that several
subprojects' tests are currently broken under Gradle. I'd still like
to be able to run non-broken tests, though. So here I'm disabling the
failing tests. The intent is to treat these exclusions as a to-do
list. We can remove exclusions as we get the corresponding tests
working. No more exclusions means
<https://github.com/liblit/WALA/issues/5> is fixed.
These settings files currently are generated with an initial timestamp
comment line, which is not something we'd want to track in version
control. Fortunately, the contents of these files are entirely
mundane, so there should be no problem with having Buildship generate
them anew each time a developer imports WALA into Eclipse as an
existing Gradle project.
Apparently Buildship generates these when one uses Import -> Existing
Gradle Project:
<https://discuss.gradle.org/t/buildship-eclipse-plug-in-multiproject-builds/24030/5>.
We can use the Gradle "eclipse" plugin if customizations are
necessary, but my impression is that the intent is to treat ".project"
and ".classpath" as generated files, not sources to be tracked in
source control.
I was confused about the differences among:
srcDir 'foo'
srcDirs ['foo']
srcDirs = ['foo']
As it turns out, the first two append to the set of source
directories, while the last replaces this set entirely. I generally
want replacement, since WALA's current directory layout never matches
Gradle's assumed defaults.
The main requirement here is to arrange for the proper classpath
settings when tests are running so that they can find any associated
resources (i.e., other supporting files).
This gives the WALA maintainers the option of doing future 1.4.5+
releases from of a pre-Gradle branch if these merged Gradle changes
turn out to be more disruptive than expected.
This should give us a set of mutually-consistent jars rather than
picking up random, outdated pieces from Maven Central or wherever else
I could find them. We now also have a single, central place where we
set the Eclipse version that we're building against. Much, *much*
cleaner.
Previously Buildship removed its classpath from all of these
launchers. Now it's automatically putting that back in as soon as I
visit each launcher in Eclipse's "Run Configurations" dialog. Not
sure what's going on here, but it certainly seems more sane to me to
assume that the Buildship-computed classpath *is* needed for all of
these. I have an open question on the Gradle discussion forum to try
to understand what's going on here and how to fix it:
<https://discuss.gradle.org/t/launchers-lose-buildship-classpath-on-import-regain-it-later/25641>.
<https://github.com/liblit/WALA/issues/5> notes that several
subprojects' tests are currently broken under Gradle. I'd still like
to be able to run non-broken tests, though. So here I'm disabling the
failing tests. The intent is to treat these exclusions as a to-do
list. We can remove exclusions as we get the corresponding tests
working. No more exclusions means
<https://github.com/liblit/WALA/issues/5> is fixed.
These settings files currently are generated with an initial timestamp
comment line, which is not something we'd want to track in version
control. Fortunately, the contents of these files are entirely
mundane, so there should be no problem with having Buildship generate
them anew each time a developer imports WALA into Eclipse as an
existing Gradle project.
Apparently Buildship generates these when one uses Import -> Existing
Gradle Project:
<https://discuss.gradle.org/t/buildship-eclipse-plug-in-multiproject-builds/24030/5>.
We can use the Gradle "eclipse" plugin if customizations are
necessary, but my impression is that the intent is to treat ".project"
and ".classpath" as generated files, not sources to be tracked in
source control.
I was confused about the differences among:
srcDir 'foo'
srcDirs ['foo']
srcDirs = ['foo']
As it turns out, the first two append to the set of source
directories, while the last replaces this set entirely. I generally
want replacement, since WALA's current directory layout never matches
Gradle's assumed defaults.
The main requirement here is to arrange for the proper classpath
settings when tests are running so that they can find any associated
resources (i.e., other supporting files).
This change affects both top-level subdirectory names as well as
Eclipse plug-in feature names. Perhaps it would have been possible to
change only the latter, but I don't like the idea of the two being
different.
These name changes fix three Eclipse plug-in warnings of the form:
Illegal value '...-feature' for attribute 'id'.
Legal token characters are "a-z", "A-Z", "0-9", "_". Tokens
must be separated by "."
I'll be the first to admit that I know nearly nothing about Eclipse
plug-in development. If changing these plug-in feature IDs has
broader implications that the automated regression tests won't detect,
then I probably overlooked them too. I would greatly appreciate
skeptical review of this change by someone who knows Eclipse plug-in
development well.
Note that personal Eclipse workspaces may need some manual adjustment
after this change. The three "...-feature" Eclipse projects should be
removed from the workspace, and the three corresponding "..._feature"
Eclipse projects should be added. If you do your git pull using
Eclipse's team features, perhaps it is smart enough to do this for
you? I don't know, but it wouldn't surprise me if fixing things
manually were still needed even in that case.
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.
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.
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.
These should mostly be things that we've already decided earlier that
we explicitly don't want to "fix" because they simply disagree with
the WALA project's coding style.
The additional diagnostics are ones that were previously being
ignored, but which we seem to have been ignoring by default rather
than as a conscious choice.
For diagnostics of which we currently have *zero* instances, treat
these as errors rather than merely warnings. The intent is to
permanently lock out future regressions of things we've completely
fixed. In the future, whenever we fix the last instance of a given
warning in a given Eclipse project, we should also promote that
diagnostic to an error to keep things clean into the future.
This fixes five Eclipse "Source folder '...' does not have the output
folder in corresponding output entry 'output..'" warnings in the
"Plug-in Development" category.
The "potentially" qualifier is here because these methods are visible
outside the WALA source tree. These methods may seem OK to be static
based on the code we have here, but we have no way of knowing whether
third-party code expected to be able to subclass and override. I'm
going to play it safe and assume that we want to allow that.
Note that we are still allowing Eclipse warnings about methods that
can *definitely* be declared static; a different configuration option
controls these. For private methods, final methods, and methods in
final classes, if the code seems static-safe based on what we have
here, then that's good enough: we don't need to worry about
third-party overrides.
This fixes 49 Eclipse code style warnings. I'm not sure why these
were overlooked in my previous sweep of missing-@Override warnings.
Ah well; got 'em this time around.
Specifically, these are all warnings of the form "The
'javacProjectSettings' build entry should be set when there are project
specific compiler settings".