Commit Graph

124 Commits

Author SHA1 Message Date
Manu Sridharan 49628fdf44 Start new development version 2018-08-22 12:01:19 -07:00
Manu Sridharan 6b46ce4faa Version 1.5.0 2018-08-22 11:19:51 -07:00
Ben Liblit 209086f068 Bump version to 1.5.0-SNAPSHOT before merging with WALA master
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.
2018-04-18 11:29:29 -05:00
Ben Liblit c16f172932 Find Eclipse jars using local Maven mirror of Eclipse P2 repository
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.
2018-04-18 11:29:28 -05:00
Ben Liblit 89860b53bb Let Buildship create new settings files when importing
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.
2018-04-18 11:29:25 -05:00
Ben Liblit 310ef1daa5 Exclude Eclipse ".project" and ".classpath" from version control
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.
2018-04-18 11:29:25 -05:00
Ben Liblit 1432e18c37 Clean up some simple syntactic redundancy in dependency declarations 2018-04-18 11:29:25 -05:00
Ben Liblit 5d5fa18b5f Replace source directories rather than appending to them
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.
2018-04-18 11:29:25 -05:00
Ben Liblit 377d7586ef Consistently use simple sorted order for dependencies
This isn't even sorting by library or subproject name.  It's just a
dumb textual sort of the contents of each line.
2018-04-18 11:29:25 -05:00
Ben Liblit 9e905c7a04 More Gradle dependency clean-ups suggested by linter
Unfortunately the linter does not reach a fixpoint if you keep trying
to apply its suggestions.  If you include "compile
'org.eclipse.core:org.eclipse.core.runtime:3.10.0.v20140318-2214'" in
the dependencies for "com.ibm.wala.ide.jdt", then the linter tells you
that this dependency is unused and can be removed.  If you remove it,
then the linter tells you that it should be added.  Sigh.
2018-04-18 11:29:24 -05:00
Ben Liblit 2ef04905c2 Additional explicit dependencies suggested by Gradle linter 2018-04-18 11:29:24 -05:00
Ben Liblit f41baeb0f8 Add a direct dependency that previously we picked up transitively 2018-04-18 11:29:24 -05:00
Ben Liblit 530d74929f Many improvements to Gradle build support, including within Eclipse 2018-04-18 11:29:24 -05:00
Ben Liblit 99c2493e37 Revert "Build WALA using Gradle instead of Maven" (#298) 2018-04-18 12:15:56 -04:00
Ben Liblit 6639d8b93a Bump version to 1.5.0-SNAPSHOT before merging with WALA master
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.
2018-04-17 15:32:01 -05:00
Ben Liblit 5e0e251766 Find Eclipse jars using local Maven mirror of Eclipse P2 repository
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.
2018-04-17 15:02:36 -05:00
Ben Liblit efd3a6ab18 Let Buildship create new settings files when importing
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.
2018-04-17 15:02:35 -05:00
Ben Liblit be11083cd8 Exclude Eclipse ".project" and ".classpath" from version control
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.
2018-04-17 15:02:35 -05:00
Ben Liblit db348b4ddd Clean up some simple syntactic redundancy in dependency declarations 2018-04-17 15:02:35 -05:00
Ben Liblit 651f40c170 Replace source directories rather than appending to them
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.
2018-04-17 15:02:35 -05:00
Ben Liblit aae1c2230a Consistently use simple sorted order for dependencies
This isn't even sorting by library or subproject name.  It's just a
dumb textual sort of the contents of each line.
2018-04-17 15:02:35 -05:00
Ben Liblit 4bb91b4bba More Gradle dependency clean-ups suggested by linter
Unfortunately the linter does not reach a fixpoint if you keep trying
to apply its suggestions.  If you include "compile
'org.eclipse.core:org.eclipse.core.runtime:3.10.0.v20140318-2214'" in
the dependencies for "com.ibm.wala.ide.jdt", then the linter tells you
that this dependency is unused and can be removed.  If you remove it,
then the linter tells you that it should be added.  Sigh.
2018-04-17 15:02:35 -05:00
Ben Liblit b94390f2fe Additional explicit dependencies suggested by Gradle linter 2018-04-17 15:02:35 -05:00
Ben Liblit 22b59de491 Add a direct dependency that previously we picked up transitively 2018-04-17 15:02:35 -05:00
Ben Liblit 401fbaf89a Many improvements to Gradle build support, including within Eclipse 2018-04-17 15:02:35 -05:00
Ben Liblit 6546d5d6a4 Resolve the last two Eclipse warnings about using raw types
Fixes bug #244.
2018-04-13 12:53:33 -05:00
Ben Liblit 0286c2b048 Use Iterator2Iterable helper to convert more loops to for-each 2017-12-04 14:04:39 -08:00
Ben Liblit ebfd885d22 Use modern for-each loops where possible
Java sources used as test data have been excluded from this mass
clean-up.
2017-11-28 14:44:53 -06:00
Ben Liblit e89c5c6562 Disable deprecation warnings in modules where they are unavoidable (#263)
These two modules refer to "AST.JLS8".  If you have Java 9 installed,
then "AST.JLS8" is marked as deprecated, and we can a warning unless
we suppress or disable the deprecation warning wherever "AST.JLS8" is
used.  However, if you don't have Java 9 installed, then "AST.JLS8" is
not deprecated, and trying to suppress deprecation warnings where
"AST.JLS8" is used instead produces warnings about unnecessary warning
suppression.  Aagh!  Turning off the deprecation warnings entirely for
these two modules seems like the only sane compromise.
2017-11-21 18:00:43 -08:00
Ben Liblit d79707e137 Suppress deprecation warnings about requesting an old AST version
Near as I can tell, the requests for deprecated versions here are
intentional.  The non-deprecated version (AST.JLS9) is the latest and
greatest, but as far as I can tell we really do want the older version
here.

This is similar to 6caecce3e7, though in
that case JLS8 was the non-reprecated latest version and we were still
asking for JLS3.
2017-11-19 15:43:45 -06:00
Julian Dolby b6af5267f1 java 8 changes
minor fixes, such as making CheckForFrontEndErrors more accessible
minor hacks to make stuff compile with TeaVM
2017-08-25 10:58:00 -04:00
Julian Dolby e599d58cd7 Merge branch 'master' of https://github.com/wala/WALA 2017-08-16 14:50:12 -04:00
Julian Dolby 3371e23de0 java 8 stuff 2017-08-16 14:50:01 -04:00
Ben Liblit b70d69d62f Treat many Eclipse plugin-related problems as errors
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.
2017-08-16 11:36:46 -07:00
Julian Dolby 4a33c527d2 Merge branch 'master' of https://github.com/wala/WALA 2017-08-15 18:01:41 -04:00
Ben Liblit d73b11fd8f Escalate switch-related diagnostics from warnings to errors
We have fixed all of these that Eclipse reports.  Treating them as
errors in the future should help us keep moving in the direction of
cleaner code.
2017-08-15 14:55:34 -07:00
Ben Liblit ab791f8c41 Throw a loud exception if switch encounters unexpected enum value
Previously each of these `switch` statements would implicitly do
nothing if an unanticipated `enum` value came along.  My impression is
that each of these `switch` statements is supposed to be exhaustive,
such that an unexpected (unhandled) value should never appear.  If one
does, we should recognize it and complain loudly.

Of course, sometimes the right behavior for previously-unhandled
values is to do nothing.  It may not always be clear whether an
exception or doing nothing is the right choice.  For this commit,
WALA's regression tests still pass even with the possibility of
throwing an exception for unexpected values.  If we assume that the
test suite is thorough, that tells me that throwing an exception is
the right policy for each `switch` statement that I'm changing here.
2017-08-15 14:55:34 -07:00
Julian Dolby 6431cbeb60 java 8 2017-08-15 12:39:19 -04:00
Manu Sridharan e8bdf2f8f9 version 1.4.4-SNAPSHOT 2017-08-06 07:25:20 -07:00
Manu Sridharan d901b13425 version 1.4.3 2017-08-05 20:52:32 -07:00
Ben Liblit 6087b73cee Fix or suppress all 242 Eclipse warnings about unused parameters
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.
2017-07-31 15:29:00 -07:00
Ben Liblit 191904d607 Remove "throws XYZ" declarations where XYZ cannot be thrown
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.
2017-07-28 10:20:28 -07:00
Ben Liblit ec0d7354ef Disable Eclipse warnings about empty statements
Previously we had 5 such warnings.  That's not very many, but it
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.
2017-07-18 20:43:36 -07:00
Ben Liblit 10dff7fb1c Disable Eclipse warnings about assignments to parameters
Previously we had 227 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.
2017-07-18 20:43:36 -07:00
Ben Liblit d3c4200bc3 Disable Eclipse warnings about name shadowing
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.
2017-07-18 20:43:36 -07:00
Ben Liblit 1d27ca974b Upgrade raw-types-usage warnings to errors where possible
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.
2017-07-12 10:39:06 -07:00
Ben Liblit e316471d88 Fix nearly all Eclipse warnings about using raw types
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.
2017-07-12 10:39:06 -07:00
Ben Liblit 0bbe9970c6 Enable Eclipse Oxygen's new "unlikely argument types" diagnostics
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.
2017-07-08 13:22:00 -07:00
Ben Liblit 3187d09c1f Roll some diagnostics back to ignore instead of warning or error
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.
2017-06-26 11:16:09 -07:00
Ben Liblit fb9042d3a6 Activate more Eclipse diagnostics, and treat many warnings as errors
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.
2017-06-26 11:16:09 -07:00