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.
It's unclear whether the original authors of these pages intended them
to be valid or invalid. Certainly there is merit in testing against
invalid HTML, since the vast majority of real-world HTML is indeed
invalid. I'm going to assume that any errors in this collection of
test inputs are intentional, and therefore not worth reporting when
running Eclipse HTML validation.
Plugin documentation includes plenty of invalid HTML. However, we
don't maintain 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.
It's unclear whether the original authors of these pages intended them
to be valid or invalid. Certainly there is merit in testing against
invalid HTML, since the vast majority of real-world HTML is indeed
invalid. I'm going to assume that any errors in this collection of
test inputs are intentional, and therefore not worth reporting when
running Eclipse HTML 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.
This fixes one Eclipse "no valid properties files exist in the
localization directory specified" warning.
Ordinarily I would also change this project's configuration to treat
this warning as an error in the future. That's a good way to
discourage regressions. Unfortunately in this particular case I
cannot find a setting that has the desired effect, even after hunting
around in Eclipse PDE sources. It seemed that setting
"compilers.p.unknown-resource=0" in
"com.ibm.wala.util/.settings/org.eclipse.pde.prefs" should do the
trick, but it does not. I don't know why.
This resolves one Eclipse "'...' build entry is missing" warning.
Also update the project configuration to treat this warning as an
error. This should discourage commits that create new instances of
this sort of problem in the future.
This resolves one "'...' is not a source folder" Eclipse warning.
Also update the project configuration to treat this warning as an
error. This should discourage commits that create new instances of
this sort of problem in the future.
Other subdirectories' "build.properties" generally seem to include this
already, so who am I to argue?
This resolves one "An entry for META-INF/ is required in bin.includes"
Eclipse warning.
Also update the project configuration to treat this warning as an
error. This should discourage commits that create new instances of
this sort of problem in the future.
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.
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.
Manu Sridharan
Ben Liblit
Julian Dolby
Michael Herzberg
Manu Sridharan
Julian Dolby
Julian Dolby