Failed requirements in cast functions

[CaelmBleidd]

Description

Sometimes requirement inside of the cast function in the engine fails.

To Reproduce

Steps to reproduce the behavior:

1. Create a project with following code:

public interface VirtualInvokeInterface<T1, T2> {
    int narrowParameterTypeInInheritorObjectCast(T1 object);

    int narrowParameterTypeInInheritorArrayCast(T2 object);
}

public class VirtualInvokeClass implements VirtualInvokeInterface<Integer, byte[]> {
    @Override
    public final int narrowParameterTypeInInheritorObjectCast(Integer object) {
        if (object == null) {
            return 0;
        }

        if (object == 1) {
            return 1;
        }

        return object;
    }

    @Override
    public final int narrowParameterTypeInInheritorArrayCast(byte[] object) {
        if (object == null) {
            return 0;
        }

        return object[0];
    }
}

public class Example {
    public int narrowParameterTypeInInheritorArrayCastExample(VirtualInvokeInterface<byte[], Integer> callee, Integer param) {
        return callee.narrowParameterTypeInInheritorArrayCast(param);
    }

    public int narrowParameterTypeInInheritorObjectCastExample(VirtualInvokeInterface<byte[], Integer> callee, byte[] param) {
        return callee.narrowParameterTypeInInheritorObjectCast(param);
    }
}

3. Run generation for narrowParameterTypeInInheritorArrayCastExample and narrowParameterTypeInInheritorObjectCastExample functions
4. Open the generated tests

Expected behavior

At least, the engine should not fail. Probably, I expect to have two branches in each example.

Actual behavior

Failed requirements in castObject and castArray function.

Visual proofs (screenshots, logs, images)

Environment

There is no specific environment.

Additional context

An initial problem occurred on the following line of code: String.format("%02d", intNumber)

[CaelmBleidd]

I investigated this issue a bit and the problem occurs because an interface invokes of a function that has some specification in an implementor of the interface (maybe it is not the only case).

There is a sequence of problems that led the engine to fail:

1. When we face an instruction with a call of the function, we are looking for any information about its caller's type, and do not find anything because of not complete generics support (Processing generics type info #924)
2. After that, we take every instantiable type and look for the method with a particular sub-signature. Due to some reasons, any class that overrides a generic function with some specification contains two of them: foo(T1) and foo(Int), for example. Since we a looking for a function with a specific sub-signature, we will pick the first one. If we chose the second one, there would not be an error.
3. After we picked foo(T2), we will add constraints for its argument type, but it won't change anything, because there is no connection between T2 and Int from the specification of the class.
4. Inside this function there is code:

arg = (Int) T2
foo(arg)

It is a place where the engine fails.
5. As an additional effect, it will produce extra class cast exceptions when it will try to cast an object to the integer type.

At the moment, I don't have a fix I'd be satisfied with. Probably, the answer is somewhere with providing additional connection between Int from the class signature and T2 from its interface. But I do have a temporary fix that might be used both for additional investigation and as a local solution for the described problem: a link to the commit