Make UtExecution abstract, introduce UtFailedExecution as its child

[dtim]

Description

Make UtExecution abstract, introduce UtFailedExecution as its child.

Rationale

There is a UtExecution class that represent any execution regardless of the way it has been found. It has two subclasses, UtSymbolicExecution and UtFuzzedExecution. The separation of these entities is artificial: UtSymbolicExecution contains data provided by the symbolic engine and used by the summarizer that UtFuzzedExecution does not have. Having two distinct child classes instead of a single UtExecution allowed the summarizer to correctly handle executions coming from two sources, the symbolic engine and the fuzzer.

There is another special kind of execution: an execution that is produced by a concrete executor when running the method leads to a failure (e.g., JVM crash). It is not possible to produce any "after state" in this case, and the execution result is always a failure.

Currently these executions are created as just UtExecution instances, and summarizer ignores them (see #800). As a result, executions may be lost.

It is necessary to correctly process these failed executions in the summarizer, and to distinguish them from "normal" executions. It seems not very convenient to make explicit checks to distinguish between a parent class and its subclasses.

This PR uses the following approach.

1. Introduce a new class, UtFailedExecution, that is a subclass of UtExecution but has a restricted set of parameters so we can't create a "successful" failed execution instance by mistake.
2. Make UtExecution abstract to prevent creating "unclassified" execution instances.

That way the summarizer can explicitly handle failed executions and generate correct summaries for them.

Limitations

This solution seems not to be "final" in any way. We have to properly define the interface between execution producers (fuzzer, symbolic engine, concrete executor, or any other kind of producer that can be added in the future) and the summarizer. In particular, it seems right to separate executions not by their source but by a set of available information (e.g., basic executions, executions with attached Jimple/bytecode/source code information, summarizer-annotated executions and so on). Maybe the additional data can be attached in some general form as annotations instead. This "correct" refactoring is a major enterprise and can't be performed immediately.

At the same time, we need to fix the issue with lost executions, so an "intermediate" refactoring is necessary.

Related issue: #800

Type of Change

• Refactoring (typos and non-functional changes)

How Has This Been Tested?

Automated Testing

All existing unit tests should pass.

Manual Scenario

None (it will be possible to test the fix for #800, for which this refactoring is a prerequisite).

Checklist (remove irrelevant options):

This is the author self-check list

• The change followed the style guidelines of the UTBot project
• Self-review of the code is passed
• The change contains enough commentaries, particularly in hard-to-understand areas
• New documentation is provided or existed one is altered
• No new warnings
• New tests have been added
• All tests pass locally with my changes

[amandelpie]

@dtim @Markoutte I remember that month ago we discussed that it could be UTExecution which are not defeined on early stages what it is (fuzzing or symbolic). Could we do this changes? Do we really cover by UtSymbolic/UtFuzzing/UtFailed all variants of the UtExecution at this momemnt?

[Markoutte]

Looks like it covers all at the moment. Isn't it a problem when we add another implementation for UtExecution for a summarization?

[dtim]

I think that major changes in summarization/engine/fuzzer interfaces will require another refactoring anyway. In this PR I just want to distinguish more clearly between all possible execution types, to make it easier (as I see it, I may be wrong) for the summarizer to check for failed executions.

If the issue #800 can be fixed without this hierarchy change, it's OK for me to drop this PR and discuss a better/conceptually correct refactoring. I think that the final decision is up to @amandelpie

[Damtev]

LGTM