Implement option to print unresolved methods to file

[phreppo]

This PR implements the possibility to dump the methods that Mariana Trench was not able to resolved to a unresolved-methods.json file.
By setting the --dump-unresolved-methods flag, the unresolved calls are printed to a unresolved-methods.json file.
The number of unresolved calls is logged into the metadata.json file.
This feature is useful for the user of the analyzer to detect which method were not resolved (and could then lead to false negatives).

[arthaud]

Thanks, I think that's useful.

Could we rename the option to --dump-unresolved-calls though? "unresolved methods" is a bit confusing.
Also, could you explain why we are doing this in the forward and backward analysis? The more natural place to collect unresolved calls is in the call graph construction.
And finally, wouldn't you want to also log the caller and possibly line/column number?

[phreppo]

I have been discussing with @the-storm, and including the information about the call site for the methods that have not been resolved could generate noise in the output. The interesting information is which methods are not being resolved, so that the user of the analyzer can try to provide the needed code to reduce the number of false negatives. By not including the information about the call site we effectively log the unresolved methods rather than the calls, hence the name of the flag.

Regarding the fact that we could collect the unresolved calls in the call graph construction: I did not know that! The reason why I went this way is that by inspecting the code, there is a logging statement in the same place where I put the collection of the unresolved methods:

mariana-trench/source/TransferCall.cpp

Lines 159 to 164 in 5566351

	statistics.log_unable_to_resolve_call(instruction->get_method());
	WARNING_OR_DUMP(
	context,
	3,
	"Unable to resolve call to `{}`",
	show(instruction->get_method()));

I though it was the best place to put the collection of unresolved calls, since logging happens there. Do you know if there is a specific reason for logging to be there rather than the call graph construction?

Thanks!

[arthaud]

Do you know if there is a specific reason for logging to be there rather than the call graph construction?

I think it should be in both. It's still useful there in case someone is looking at the logs for that specific caller method (using --log-method).