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.
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.
Ben Liblit
Manu Sridharan
Julian Dolby
Michael Herzberg
Manu Sridharan
Julian Dolby
Julian Dolby