These were not producing warnings in the Eclipse Oxygen GUI, and also
produced no warnings from Tycho when running Maven tests on my local
machine. However, they did result in errors under Travis-CI. I'm not
sure why this inconsistency exists, but hopefully we have now fixed
these raw-type uses in a way that makes everything happy.
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.
Generally, overriding one means you should be overriding the other
too.
Also, configure Eclipse to treat any similar cases as errors, rather
than merely warnings.
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.
In certain cases, one may want to ignore inter-procedural control
dependence. Consider the following example:
flag = getFlagVal();
if (flag) {
doStuff();
}
If we are ignoring interprocedural control dependence, a forward slice
from the first statement will *not* include statements inside doStuff()
and its transitive callees.
This option is useful in scenarios where the effects of statements
inside control-dependent callees can be accounted for via some cheaper
effect analysis. E.g., if you only care about heap effects of control-
dependent callees, you can compute that using mod-ref analysis,
rather than sucking all the control-dependent callee statements into the
slice.
Also added some more detailed comments, a new unit test, and removed
some trailing whitespace.
In all of these cases, the code used to initialize the unused local
seems nontrivial to me. I think this can all be removed without
erasing any needed side effects, but the code might still become
useful to someone in the future. So I'm not really removing the code
entirely, but merely commenting it out.
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.
* Fix warnings about unset javacProjectSettings build entries
Specifically, these are all warnings of the form "The
'javacProjectSettings' build entry should be set when there are project
specific compiler settings".
* Add @Override annotations to all methods that do override
This fixes 287 Eclipse code style warnings.
* Cannot add @Override annotations here, so suppress warnings instead
We should be able to add these @Override annotations in the future,
one Eclipse Mars and earlier are no longer supported. For now,
though, they have to go away in order to be compatible with older
Eclipse releases.
Specifically, these are all warnings of the form "The
'javacProjectSettings' build entry should be set when there are project
specific compiler settings".
* 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.
* Use IAnalysisCacheView instead of AnalysisCache. (#1)
It seems that some additional types need to be changed due to
d24519e974. This may not be inclusive,
however.
* Increase visibility of several methods and constructors.
Used for creating custom contexts and context selectors.
* Ignore the results directory.
* Some generic type fixes in ModRef.java.
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.
Removing an unused field sometimes means removing constructor code
that used to initialize that field. Removing that initialization code
sometimes leaves whole constructor arguments unused. Removing those
unused arguments can leave us with unused code to compute those
arguments in constructors' callers, and so on. This commit tries to
clean all of this up, working backward from the unused fields that an
earlier commit already removed. Hopefully I have avoided removing
upstream code that had other important side effects, but it wouldn't
hurt for a WALA expert to review this change carefully.
Manu requested that we use this approach instead of adding
`@SuppressWarnings("unused")` at each affected catch block. That
seems reasonable to me, given the large number of such warnings and
the lack of likely harm from ignoring such caught exceptions.
Fixing these Javadoc comments would require adding packages to various
other packages' build paths. In some of the cases suppressed,
changing build paths in that manner would create circular build
dependencies. In other cases, it would simply add a Javadoc-motivated
dependency that does not exist for the real code, which seems
undesirable. For a few cases, the reference seems to be to types in
code we don't even have here, such as code from "android" or
"org.mozilla" packages.
These arise, for example, when Javadoc documentation on a public class
includes a @link to a private field. I can see how this would be
problematic for closed-source Java code where private items are
invisible to outsiders. However, given that WALA is open source,
nothing is truly non-visible. If the WALA documentation authors
considered non-visible references useful when explaining things,
that's fine with me.
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.
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.
As it turns out, I should have been using "? extends InstanceKey" rather
than "? super InstanceKey". But really, we can just use "?" here since
HeapGraph itself constrains its own type parameter appropriately.
In the cases addressed here, the caught exception was being "handled"
by throwing some new exception. Instead of discarding the old
exception, pass it to the new exception's constructor to indicate the
original cause of the newly-created exception. This practice, called
"exception chaining", can often be useful in debugging.
Note: some of these methods are decidedly nontrivial. Perhaps they
should not actually be removed? If any should be kept around, please
identify them to me. I'll revise this change to retain those methods
and simply annotate them as needed to suppress Eclipse's warning.
Eclipse warns that the "if" statements' true blocks are dead, and
indeed the conditions being tested here can never be true. It's a
little subtle why that's so, though. Changing them to "assert"
statements removes two warnings about deprecated code, while still
helping human readers understand what invariants must hold here.
All of these involve conditionals that check some static, final debug
flag or debug level. The code will indeed be dead if WALA is built
with those debug facilities turned off. But we still want the code
present in case someone needs to turn some aspect of debugging on for
a while.
The supposedly deprecated function (CGNode.addTarget) really seems to
be intended for internal use, not deprecated per se. We are an
internal user here, so presumably it's OK for us to be using this API
entry point.
Since SSAPhiInstructions are never visited by NullPointerTransferFunctionProvider.TransferFunctionSSAVisitor,
we now respect phi instructions present at a given block by providing additional NodeTransferFunctions, improving precision.
Formerly, meets would lead to incorrect results due to incorrect initialization of initial data flow facts.
These are now properly initialized, interpreting
"State.BOTH" to mean: both "null" and "non-null" are possible values for the given variable, and
"State.UNKNOWN" to be the absurd assertion.
The initial fact at the entry block assumes variables to be BOTH, other blocks are initialy assumed unreachable and hence their variables to be UNKNOWN.
The setting should comply with the comment. Plus,
turning it on seems to lead to some unsoundness because
exception points-to sets become empty but should not be
Access is provided via corresponding methods in FieldImpl, ShrikeCTMethod and ShrikeClass.
Since we do not currently have implementation of these methods for front-ends other than Shrike, these new methods are not yet made available in the corresponding interfaces.
Some of these might have proper DTDs or XML Schema definitions
floating around somewhere that we could use. Presumably many do not.
Rather than hand-craft such definitions myself, I'm just giving each a
minimal stub DOCTYPE declaration. That's enough to satisfy Eclipse's
XML validator, which otherwise complains that these files lack grammar
constraints.
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.
Ant "build.xml" files don't have a standard DTD or XML Schema; the
contents are simply too flexible for that. But we can at least
give each a stub DOCTYPE declaration. That's enough to satisfy
Eclipse's XML validator, which otherwise complains that these files
lack grammar constraints.
Most of the invalid HTML arose from bare "<" and ">" characters.
These should be escaped as "<" and ">" when not intended to
introduce HTML tags. When you have many such characters close
together, "{@literal ...}" is a nice, readable alternative that
automatically escapes its contents. If the text in question is
intended to be a code fragment, then "{@code ...}" is appropriate:
this is essentially equivalent to "<code>{@literal ...}</code>".
There were a few other HTML violations too, but none common enough to
be worth detailing here.
The contents of @author go straight into HTML, just like most other
Javadoc material. So if you want to have a "<foo@bar.com>" e-mail
address as part of the author information, the angle brackets must be
escaped. Here I've opted to do that using "{@code <foo@bar.com>}",
which has some additional styling effects that seem appropriate for
e-mail addresses. We could also have used "<foo@bar.com>" for
escaping without code styling.
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.
A subclass of TabulationSolver can now override the methods
newNormalExplodedEdge(), newCallExplodedEdge(), and
newReturnExplodedEdge() to take some action whenever (logically)
some edge in the exploded supergraph is "discovered" during
tabulation.
These methods were constructing an IR based on some default
AnalysisOptions, which may not match the options used when constructing
the underlying CallGraph. This mismatch can lead to bad bugs.
Instead of these methods, analyses should get IR directory from the
CGNodes via CGNode.getIR().
Ideally we would fix the methods and not change the interface, but
that would require knowing the right AnalysisOptions, which itself
would necessitate an interface change.
Julian Dolby
Ben Liblit
Manu Sridharan
Manu Sridharan
Raffi Khatchadourian
Martin Mohr
Martin Hecker
Manu Sridharan
Julian Dolby
Andreas Sewe
steohan
Stephan Gocht