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.
Removing fixes one Eclipse error diagnostic: "Default encoding (UTF-8)
for library '.' should be removed as the workspace does not specify an
explicit encoding."
This reapplies the fox from ecd1ff72fe,
which was reverted (apparently unintentionally) as part of a larger
group of changes in 8d65788aef.
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.
currentSite should be ThreadLocal because not having this screws up a lot of the instrumentation-based dynamic call graphs we generate for the shootout benchmarks.
I have also conditionally changed how the string of the currentSite is created based on the output format that Julian came up with for the dynamic call graph. This support is necessary, because the Java std libraries are not instrumented. Therefore, they would appear as if calls from them show up from nowhere in the log that WALA generates for the dynamic call graph. This fix make those calls originate from a fake library BLOB node in the call graph.
- adding multi-flow AnalysisOption
- enable/disable special handling of zero-length arrays
Both are required to enable precise analysis of some Dacapo benchmarks when using the Averroes-generated summaries
This fixes two Eclipse Plug-in Development warnings of the form "Key
'...' is not found in localization properties file:
OSGI-INF/l10n/bundle.properties".
This fixes two Eclipse Plug-in Development warnings of the form "The
'javacProjectSettings' build entry should be set when there are
project specific compiler settings".
This removes three Eclipse Plug-in Development warnings of the form
"This plug-in does not export all of its packages"
I assume that omitting some exports is OK, because apparently nothing
else fails to build against these. If an omitted export were needed
elsewhere, something would fail to build.
This change affects both top-level subdirectory names as well as
Eclipse plug-in feature names. Perhaps it would have been possible to
change only the latter, but I don't like the idea of the two being
different.
These name changes fix three Eclipse plug-in warnings of the form:
Illegal value '...-feature' for attribute 'id'.
Legal token characters are "a-z", "A-Z", "0-9", "_". Tokens
must be separated by "."
I'll be the first to admit that I know nearly nothing about Eclipse
plug-in development. If changing these plug-in feature IDs has
broader implications that the automated regression tests won't detect,
then I probably overlooked them too. I would greatly appreciate
skeptical review of this change by someone who knows Eclipse plug-in
development well.
Note that personal Eclipse workspaces may need some manual adjustment
after this change. The three "...-feature" Eclipse projects should be
removed from the workspace, and the three corresponding "..._feature"
Eclipse projects should be added. If you do your git pull using
Eclipse's team features, perhaps it is smart enough to do this for
you? I don't know, but it wouldn't surprise me if fixing things
manually were still needed even in that case.
Specifically, this will run the "javadoc" goal of the
"maven-javadoc-plugin" and the "plugin-source" goal of the
"tycho-source-plugin" whenever Eclipse does a full build. It will not
run these on incremental builds, though. Maven plugins in general are
usually not designed with incremental execution in mind, so rerunning
them on every incremental build turns out to be too sluggish in
practice.
Previously, M2Eclipse would occasionally notice these two plugins,
realize it didn't know what to do with them, and produce Eclipse error
diagnostics that were difficult to resolve. With this change we are
telling Eclipse's Maven builder to just run the plugins in the natural
way even though M2Eclipse has no special handling built-in for them.
Fixes#198, much to my relief.
I would not bother to fix indentation by itself, but it makes sense to
fix this indentation now in advance of some larger changes coming to
this file soon.
In modern Java, we would not need to do this. Java 1.8 can infer the
generic type, which would allow us to write simply
"Collections.emptySet()" instead of
"Collections.<TypeReference>"emptySet()". Unfortunately, Android is
behind the times, so this specific project targets Java 1.5. That
older Java definition does not do the inference we would want here, so
we have to be explicit instead.
The former returns Set<T> for any T, whereas the latter merely returns
a raw Set. Using the former instead of the latter fixes four Eclipse
warnings about using raw generics.
Ben Liblit
Julian Dolby
Raffi Khatchadourian
Manu Sridharan
Karim Ali
Julian Dolby