Type parameters in generated tests lead to failing of toJavaClass

[EgorkaKulikov]

Generate tests with the following ContestEstimators settings

timeLimit=60
methodFilter = "org.usvm.samples.arrays.ArrayStoreExceptionExamples.genericAssignmentWithCast"
projectFilter = listOf("samples")

The following error can be found in logs

Can't convert execution for method genericAssignmentWithCast, exception is  E
java.lang.ClassNotFoundException: E
	at java.net.URLClassLoader.findClass(URLClassLoader.java:387) ~[?:1.8.0_382]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:418) ~[?:1.8.0_382]
	at java.lang.ClassLoader.loadClass(ClassLoader.java:351) ~[?:1.8.0_382]
	at java.lang.Class.forName0(Native Method) ~[?:1.8.0_382]
	at java.lang.Class.forName(Class.java:348) ~[?:1.8.0_382]
	at org.usvm.instrumentation.util.JacodbKt.findClassInLoader(Jacodb.kt:107) ~[usvm-jvm-instrumentation-comp-231115-1620.jar:?]
	at org.usvm.instrumentation.util.JacodbKt.toJavaClass(Jacodb.kt:55) ~[usvm-jvm-instrumentation-comp-231115-1620.jar:?]
	at org.utbot.contest.usvm.ConverterUtilsKt.getClassId(ConverterUtils.kt:61) ~[main/:?]
	at org.utbot.contest.usvm.UTestInst2UtModelConverter.processExpr(UTestInst2UtModelConverter.kt:216) ~[main/:?]
	at org.utbot.contest.usvm.UTestInst2UtModelConverter.processExpr(UTestInst2UtModelConverter.kt:173) ~[main/:?]
	at org.utbot.contest.usvm.UTestInst2UtModelConverter.processUTest(UTestInst2UtModelConverter.kt:65) ~[main/:?]
	at org.utbot.contest.usvm.JcToUtExecutionConverter.<init>(JcToUtExecutionConverter.kt:60) ~[main/:?]
	at org.utbot.contest.usvm.ContestUsvmKt$runUsvmGeneration$1.invokeSuspend(ContestUsvm.kt:223) [main/:?]
	at kotlin.coroutines.jvm.internal.BaseContinuationImpl.resumeWith(ContinuationImpl.kt:33) [kotlin-stdlib-1.8.22.jar:1.8.22-release-407(1.8.22)]
	at kotlinx.coroutines.DispatchedTaskKt.resume(DispatchedTask.kt:234) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at kotlinx.coroutines.DispatchedTaskKt.dispatch(DispatchedTask.kt:166) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at kotlinx.coroutines.CancellableContinuationImpl.dispatchResume(CancellableContinuationImpl.kt:397) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl(CancellableContinuationImpl.kt:431) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at kotlinx.coroutines.CancellableContinuationImpl.resumeImpl$default(CancellableContinuationImpl.kt:420) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at kotlinx.coroutines.CancellableContinuationImpl.resumeUndispatched(CancellableContinuationImpl.kt:518) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at kotlinx.coroutines.EventLoopImplBase$DelayedResumeTask.run(EventLoop.common.kt:500) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at kotlinx.coroutines.EventLoopImplBase.processNextEvent(EventLoop.common.kt:284) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at kotlinx.coroutines.BlockingCoroutine.joinBlocking(Builders.kt:85) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking(Builders.kt:59) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at kotlinx.coroutines.BuildersKt.runBlocking(Unknown Source) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at kotlinx.coroutines.BuildersKt__BuildersKt.runBlocking$default(Builders.kt:38) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at kotlinx.coroutines.BuildersKt.runBlocking$default(Unknown Source) [kotlinx-coroutines-core-jvm-1.6.4.jar:?]
	at org.utbot.contest.usvm.ContestUsvmKt.runUsvmGeneration(ContestUsvm.kt:57) [main/:?]
	at org.utbot.contest.Tool$USVM.runGeneration(ContestEstimator.kt:257) [main/:?]
	at org.utbot.contest.Tool$UtBotBasedTool.run(ContestEstimator.kt:156) [main/:?]
	at org.utbot.contest.ContestEstimatorKt.runEstimator(ContestEstimator.kt:550) [main/:?]
	at org.utbot.contest.ContestEstimatorKt.main(ContestEstimator.kt:426) [main/:?]

The reason is that JcType used in toJavaClass contains type parameters.

[EgorkaKulikov]

@DaniilStepanov could you clarify a little more about toJavaClass expected behaviour, please.

Here it is called for a JcType containing type variable and fails.
Should something be fixed in your method implementation? Or we should implement another conversion of JcType to ClassId somehow?

This is rather often problem, it can be reproduced on org.usvm.samples.recursion.Recursion.dfs, for example.

[EgorkaKulikov]

Fixed, but now not consistent with approximations.