Julian added this in a recent commit, but has told me that he does not
think it is necessary, and that I am free to remove it if it is
causing trouble. Removing this does indeed fix one Eclipse error
diagnostic: "Default encoding (UTF-8) for library '.' should be
removed as the workspace does not specify an explicit encoding."
In Eclipse projects that currently have no definite or potential
resource leaks, treat any such diagnostics as errors in the future.
In `com.ibm.wala.core`, enable warnings about definite or potential
resource leaks. Previously these diagnostics were turned off entirely
in this project. So we actually end up with more warnings now than we
had before, but they are all warnings we should eventually look into.
These are all problems that Eclipse can detect, but that it detects no
instances of right now. Treating these as warnings instead of errors
should help prevent us from slipping backward in the future.
This fixes an Eclipse Plug-In Development warning that reads "Source
folder 'dat/' does not have the output folder in corresponding output
entry 'output..'." It is not the default quick fix that Eclipse
suggests, and I am *definitely* not sure that this is the right way to
fix this problem. (I have nearly zero knowledge of Eclipse plug-in
development.)
That being said, this change does make the warning go away, and `mvn
clean install` without `-DskipTests` still succeeds.
In particular, per the corresponding Eclipse warning, "The
`javacProjectSettings` build entry should be set when there are
project specific compiler settings".
In particular, be quiet about being unable to resolve
"org.eclipse.jdt.launching.macosx", which was already marked as
`optional` anyway. I assume that I'm missing this because I'm not
developing on MacOS, and that it would be present if I were. Can
someone using MacOS confirm this?
Of course, doing nothing isn't always the right behavior. Sometimes a
previously-unhandled value is truly unexpected and one should fail by
throwing an exception. It may not always be clear whether an
exception or doing nothing is the right choice. For some `switch`
statements affected by this commit, I initially guessed that throwing
an exception was the right default behavior, but was proven wrong when
doing so caused WALA regression test failures. That's strong evidence
that the unmatched values were not really unexpected, but merely
should have been handled by doing nothing as before.
Previously each of these `switch` statements would implicitly do
nothing if an unanticipated `enum` value came along. My impression is
that each of these `switch` statements is supposed to be exhaustive,
such that an unexpected (unhandled) value should never appear. If one
does, we should recognize it and complain loudly.
Of course, sometimes the right behavior for previously-unhandled
values is to do nothing. It may not always be clear whether an
exception or doing nothing is the right choice. For this commit,
WALA's regression tests still pass even with the possibility of
throwing an exception for unexpected values. If we assume that the
test suite is thorough, that tells me that throwing an exception is
the right policy for each `switch` statement that I'm changing here.
This `switch` statement currently covers all possible values of the
`enum` it is testing. However, if a new value were introduced in the
future, the `switch` would have been silent about it instead of
printing a debug message as is done in all of the other cases. Better
to print *some* kind of debug in the default case too.
This `switch` statement currently covers all possible values of the
`enum` it is testing. However, if a new value were introduced in the
future, the `switch` would have allowed control-flow to fall through
by default instead of throwing an exception as is done in all of the
other cases. Better to throw *some* kind of exception in the default
case too.
Eclipse was warning that these `switch` statements had no `default`
cases. Each did have some default behavior, but implemented outside
the `switch`. By moving the default behavior into a `default` case
within the `switch`, we eliminate a static warning with no change
whatsoever to the run-time behavior.
Eclipse was warning about the lack of a `default` case in the `switch`
statement. None of the current `enum` values was actually missing
from the `switch`, but if the enum values list were extended in the
future, that would be an easy mistake to make.
Replacing the `switch` with dynamic dispatch to a method lets us
statically enforce the requirement that every enum value must
implement the behavior in some way.
Instead of having two `switch` statements on the Dot format
enumeration, give each Dot enumeration value a way to identify its own
preferred file suffix and command-line format name. This removes some
warnings about `switch` statements without default cases. It also
creates strong static enforcement that any new Dot format *must* also
provide this information.
Casting to `Foo<Bar>` results in an unchecked-cast warning due to Java
generics type erasure. However, sometimes we don't really need a
`Foo<Bar>`, but could simply use any `Foo<?>`. Casting to the latter
creates no warning.