Commit Graph

312 Commits

Author SHA1 Message Date
Ben Liblit f7dc0a06de Treat unused parameters as errors, not merely warnings
We've fixed or suppressed all such warnings, except in projects
containing test inputs.  Let's make sure no more appear in the future.
2017-07-31 15:29:00 -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 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 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
Ben Liblit 9c81cae9be Externalize bundle names and vendors
This fixes 33 Eclipse "The value for attribute '...' is not
externalized.  The value must begin with %" warnings in the "Plug-in
Development" category.
2017-06-07 17:42:11 +02:00
Ben Liblit 72c754e874 Declare private methods static wherever possible
If a method is private, there's no risk that a subclass elsewhere
might be overriding it and depending on dynamic dispatch to choose the
right implementation.  So all of these private methods can safely be
declared static without risk of regression in either WALA code or
unseen third-party code.
2017-06-07 08:29:23 -07:00
Ben Liblit e1d2fa9850 Suppress Eclipse warnings about potentially-static methods
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.
2017-06-07 08:29:23 -07:00
Ben Liblit e753aba3cc Fix warnings about unset javacProjectSettings build entries (#176)
Specifically, these are all warnings of the form "The
'javacProjectSettings' build entry should be set when there are project
specific compiler settings".
2017-05-04 11:44:32 -07:00
Ben Liblit fbf9abfa3a Fix Eclipse type-safety warnings in overrides of `ModRef` visitor-making methods (#175)
* Add missing type parameters to overrides of ModRef.makeModVisitor

* Add missing type parameters to overrides of ModRef.makeRefVisitor

This also required slightly generalizing the generic type signature of
the ModRef.makeRefVisitor return type.  Instead of returning
"RefVisitor<T, ExtendedHeapModel>", we now return "RefVisitor<T, ?
extends ExtendedHeapModel>".  We need that extra flexibility because
at least one override of this method returns a RefVisitor whose second
generic type parameter is a subclass of ExtendedHeapModel.
2017-05-03 19:37:58 -07:00
Manu Sridharan c9022b0743 update version to 1.4.3-SNAPSHOT 2017-04-19 09:19:09 -07:00
Manu Sridharan 44e433085e tag 1.4.2 release 2017-04-19 09:17:13 -07:00
Ben Liblit d35e8d0fa2 Disable Eclipse warnings about missing version constraints
Specifically, we're turning off Eclipse warnings about missing version
constraints on required bundles ("Require-Bundle"), exported
packages ("Export-Package"), and imported packages ("Import-Package").
We're not turning these off absolutely everywhere, though: only in
packages where one or more such warnings were actually being reported.
So if a given package was already providing all version constraints
for, say, package imports, then we've kept that warning on in that
package.

Honestly I don't entirely understand the practical implications of
these warnings.  However, there were 355 of them across many WALA
subprojects.  I take this as evidence that the WALA developers do not
consider these version constraints to be important.  Therefore, we may
as well stop warning about something we have no intention of fixing.

That being said, if we *do* want to fix some or all of these, I
welcome any advice on what those fixes should look like.  I am rather
ignorant about all things OSGi.
2017-03-28 20:37:41 -05:00
Manu Sridharan ab7e638c29 version 1.4.2-SNAPSHOT 2017-03-25 13:54:21 -07:00
Manu Sridharan 2d0518963d Tag release 1.4.1 2017-03-25 13:24:39 -07:00
Manu Sridharan b82e808b32 Merge pull request #156 from liblit/warning-fixes-unnecessary-code-uncontroversial
Fix 265 Eclipse warnings about unnecessary code
2017-03-23 17:48:10 -07:00
Ben Liblit 67013a0d77 Fix 21 Eclipse warnings about unnecessary warning suppressions 2017-03-23 12:28:14 -05:00
Ben Liblit e52d872e3e Fix 19 Eclipse warnings about unnecessary casts 2017-03-23 12:28:14 -05:00
Ben Liblit ea39ad647e Don't warn about Javadoc tags with missing descriptions
These changes turn off Eclipse warnings for Javadoc tags without
descriptions.  In some subprojects, we turn these off entirely.  In
others, leave on missing-descrption checks for "@return" tags only.

We don't turn this warning off in all projects.  Rather, we turn it
off only in projects that were producing at least one such warning.
In other words, if a project was already completely "clean" with
respect to this warning, then we leave this warning enabled for that
project.

Turning off these warnings is a partial declaration of Javadoc
bankruptcy.  In an ideal world, we would enable and fix all of these
warnings.  However, there are 576 of them.  Apparently the WALA team's
implicit coding style says that omitting descriptions is OK.  If
there's no intent to systematically add descriptions, then we may as
well turn off these warnings so that we can see other warnings that we
may want to fix.
2017-03-22 20:39:36 -05:00
Manu Sridharan 9b692e714f switch version to 1.4.1-SNAPSHOT 2017-03-21 09:38:36 -07:00
Manu Sridharan bfe378e7f2 1.4.0 release 2017-03-21 08:59:08 -07:00
Ben Liblit 6766f1e261 Fix 42 Eclipse warnings about unused imports 2017-03-20 00:43:48 -05:00
Ben Liblit fde65340d2 Fix 132 Eclipse warnings about using raw generic types 2017-03-15 11:08:20 -05:00
Julian Dolby bb0f38338e Merge branch 'warning-fixes-resource-management' of https://github.com/liblit/WALA 2017-03-13 10:44:38 -04:00
Ben Liblit b1678882b3 Plug numerous potential resource leaks
This fixes 33 out of 37 Eclipse "Potential resource leak: '...' may
not be closed" warnings.  It also fixes 3 out of 37 Eclipse "Resource
'...' should be managed by try-with-resource" warnings, although that
was not the main focus of this effort.

The remaining 4 warnings about potential resource leaks all involve a
leaked JarFile instance that is passed to a JarFileModule constructor
call.  JarFileModile never attempts to close its underlying JarFile;
this code is written as though JarFile cleanup were the caller's
responsibility.  However, the JarFile often cannot be closed by the
code that creates the JarFileModule either, since the JarFile needs to
remain open while the JarFileModule is in use, and some of these
JarFileModules stay around beyond the lifetime of the code that
created them.  Truly fixing this would essentially require making
JarFileModule implement Closeable, which in turn would probably
require that Module implement Closeable, which in turn would require
changes to lots of code that deals with Module instances to arrange
for them to be properly closed.  That's more invasive than I'm
prepared to take on right now.
2017-03-12 21:38:43 -05:00
Ben Liblit 994a70500f Remove redundant generic type parameters where possible
Instead, rely on Java's ability to infer type parameters in many
contexts.  This removes 665 Eclipse warnings.

Note: a few of these changes are to files under "test" subdirectories.
Presumably those are files that serve as test inputs rather than being
part of WALA code proper.  As far as I can tell, these changes do not
break any WALA tests.  But if any of those tests were specifically
intended to exercise WALA on code with non-inferred generic type
parameters, then I really should be leaving those alone.
2017-03-11 21:20:51 -06:00
Julian Dolby 5c6cf9724a Merge branch 'warning-fixes-java-versions' of https://github.com/liblit/WALA 2017-03-11 13:46:06 -05:00
Julian Dolby a8a3699ee1 type cleanups 2017-02-23 10:10:39 -05:00
Julian Dolby d24519e974 cross-cutting changes to make more of WALA runnable with TeaVM. The biggest change is refactoring to AnalysisCache and friends; since TeaVM does not support SoftReference, I needed to add a layer of interfaces so that I can use a more simpleminded caching implementation for TeaVM. There are other changes to Module and friends to break connections with File and URL, which also cause TeaVM grief. I also organized imports in many places to remove unused types that caused trouble. 2017-02-02 20:33:27 -05:00
Julian Dolby c9b1006305 changes for allowing seq. and conc. CHAs 2017-01-12 16:34:54 -05:00
Julian Dolby 7a69f752d0 type cleanups 2017-01-11 08:04:37 -05:00
Ben Liblit 522c382a19 Use consistent Java versions, usually 1.7
Previously, the various Eclipse projects' Java configurations used
mixtures of 1.6, 1.7, and 1.8.  Many were internally inconsistent,
such as requiring 1.7 in "MANIFEST.MF" but 1.6 in the Eclipse JDT
build preferences.  The Travis-CI configuration tests against both 1.7
and 1.8, but does not test against 1.6.

Across all projects, the most common version was 1.7.  So I'm going to
assume that 1.7 is the intended build target.  This commit makes 1.7
the selected version nearly everywhere.

"com.ibm.wala.core.testdata" is the one exception.  This specific
project uses a few features only found in 1.8, such as lambda
expressions.  Previously, "com.ibm.wala.core.testdata" used 1.7 in
some aspects of its configuration but 1.8 in others.  Now it
consistently targets 1.8.  I wish this one project didn't need to be
inconsistent with the rest of WALA, but at least now it's consistent
with itself.

(Personally, I'd be happy to target 1.8 only.  But my impression
across all of these configuration files is that the WALA developers
still want to be compatible with 1.7.  If that is no longer a
requirement, let me know and I will adjust these changes accordingly
to target 1.8 only.)

This change eliminates 11 "There is no 'jre.compilation.profile' build
entry and the project has Java compliance preferences set" warnings
and 13 "The JRE container on the classpath is not a perfect match to
the 'JavaSE-1.7' execution environment" warnings.  However, it also
adds 450 "Redundant specification of type arguments <...>" warnings
and 17 "Resource '...' should be managed by try-with-resource"
warnings.  So this seems like a net step backward in my wish to reduce
WALA warnings.  However, those new warnings concern Java 1.7 language
features that we were not previously using to good effect in projects
that targeted 1.6.  If we all agree that we can now target 1.7
instead, then we can use these helpful features as the newly-added
warnings suggest.  So I call that a step in the right direction.
2016-11-29 21:29:30 -06:00
Ben Liblit 18b79bf0f9 Merge branch 'master' into warning-fixes-xml-validation 2016-11-29 10:08:00 -06:00
Ben Liblit 3b1547f0a7 Exclude Maven-generated (?) files from XML validation
I think the "target/p2artifacts.xml" and "target/p2content.xml" files
are generated by Maven.  They are well-formed XML but Eclipse's XML
validator legitimately warns that they lack grammar constraints.
Since we're not maintaining the tool that creates these files, we are
not in a position to do anything about that.  Therefore, we may as
well exclude these from validation entirely.  That way we can
more-clearly recognize warnings that we *can* do something about.
2016-11-28 14:55:25 -06:00
Ben Liblit 2a5503b9aa Exclude Maven-generated HTML pages from validation
Eclipse validation warns about invalid HTML content in all
Maven-generated "target/site/dependency-convergence.html" files.  The
warnings are legitimate: these HTML files are indeed invalid.
However, we don't maintain the tool that generates these files, so we
are not in a position to fix them.  Better, therefore, to suppress
these warnings so that we can notice and fix other problems over which
we do have control.
2016-11-27 21:24:03 -06:00
Ben Liblit dace7b709f Ignore missing non-null-by-default annotations in Eclipse
In general, the WALA code base is not really ready for nullness
checking.  It would be nice if we got there some day, but I'm not
planning to take that on now or any time soon.  Until then, it's not
useful to warn about missing @NonNullByDefault declarations on WALA
packages.

See also older commit 7b6811b.
2016-11-26 18:47:35 -06:00
Julian Dolby 0f0c3d6bd9 add more functionality to analysis engine: create SDGs and
parameterize to do both regular and field-based analysis in JavaScript
2016-08-18 22:43:12 -04:00
Manu Sridharan 315d836d18 Fix building jars with JDK 7 2016-07-22 14:46:35 -07:00
Manu Sridharan 373a4d8aa4 Update Maven Central files to allow building under Java 8 2016-07-22 12:32:51 -07:00
Ben Liblit 7b6811b2dd Ignore potential null accesses in Eclipse
Eclipse Mars Service Release 2 finds 45 potential null pointer accesses
across WALA's various Eclipse projects. Eclipse ignores these by
default, but any individual user may have changed their personal Eclipse
configuration to treat them as warnings or errors. Thus, some people
will find that the code builds while others find that it fails. Better
to explicitly use a known-good configuration.

In the long run someone should inspect these cases one-by-one and fix
them where appropriate. But that is probably better managed as part of a
larger effort to tidy up nulls in WALA. I'm not planning to take that on
now or any time soon, though, so this is a better setup for now.
2016-06-27 13:11:42 -05:00
Manu Sridharan bd58bf4515 Remove cast.java dependence on org.eclipse.core 2016-05-18 21:18:52 -07:00
Manu Sridharan c26cddf65b Maven Central build file for wala.cast.java
Work in progress
2016-05-18 21:09:50 -07:00
Manu Sridharan cd560b3b2b switch version to 1.3.10-SNAPSHOT 2016-05-10 22:53:28 +09:00
Manu Sridharan 158a5deeb0 Version 1.3.9 2016-05-10 21:59:26 +09:00
Julian Dolby e87b2e5d84 fixes for slicing of field-based CGs 2016-02-14 17:18:21 -05:00
Manu Sridharan e46bb81081 Update version to 1.3.9-SNAPSHOT 2015-10-09 12:55:49 -07:00