Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Method call resolution fails with UnsolvedSymbolException if passed parameter is a list of two or more elements #3183

Closed
mfarsikov opened this issue Mar 22, 2021 · 4 comments · May be fixed by #3194

Comments

@mfarsikov
Copy link

I'm using Javaparser 3.18.0.
The file to parse src/test/resources/MyClass.java:

import java.io.IOException;
import java.nio.file.Files;
import java.util.Arrays;

class MyClass {
    public void writeFile() throws IOException {
        Files.write(null, Arrays.asList("", ""));
    }
}

The parser (in Kotlin):

package my.package

import com.github.javaparser.ParserConfiguration
import com.github.javaparser.ast.body.ClassOrInterfaceDeclaration
import com.github.javaparser.ast.expr.MethodCallExpr
import com.github.javaparser.symbolsolver.JavaSymbolSolver
import com.github.javaparser.symbolsolver.resolution.typesolvers.ReflectionTypeSolver
import com.github.javaparser.utils.SourceRoot
import java.nio.file.Path

fun main() {
    val symbolSolver = JavaSymbolSolver(ReflectionTypeSolver())

    val sourceRoot = SourceRoot(
        Path.of("src/test/resources/"),
        ParserConfiguration().setSymbolResolver(symbolSolver)
    )

    val compilationUnit = sourceRoot.tryToParse()
        .single()
        .result.get()

    val methodCall = (compilationUnit.childNodes[3] as ClassOrInterfaceDeclaration)
        .methods.single().body.get()
        .childNodes.single()
        .childNodes.single() as MethodCallExpr

    methodCall.resolve()
}

In the attempt to resolve the method call it fails:

Exception in thread "main" UnsolvedSymbolException{context='null', name='We are unable to find the method declaration corresponding to Files.write(null, Arrays.asList("", ""))', cause='null'}
	at com.github.javaparser.symbolsolver.JavaSymbolSolver.resolveDeclaration(JavaSymbolSolver.java:167)
	at com.github.javaparser.ast.expr.MethodCallExpr.resolve(MethodCallExpr.java:313)
	at my.package.MainKt.main(Main.kt:28)
	at my.package.MainKt.main(Main.kt)

But if in parsed file list consists of a single element:
Files.write(null, Arrays.asList("", "")); -> Files.write(null, Arrays.asList(""));
it is solved correctly.

@deadlocklogic
Copy link
Contributor

I believe that this is a mix of an inference bug + maybe other bug (after a little analysis).
Actually consider this little related test:

List<MethodCallExpr> metCallExprs = cu.findAll(MethodCallExpr.class);
metCallExprs.forEach(metCallExpr -> {
    if (metCallExpr.getNameAsString().equals("asList")) {
        ResolvedType resolvedType = metCallExpr.calculateResolvedType();
        System.out.println(resolvedType.describe());
    }
});

The solved type is calculated as java.util.List<T> which is clearly wrong, it should be java.util.List<java.lang.String>.
Again, the generic part needs a lot of analysis/improvement.

@maartenc
Copy link
Contributor

Yes I think the bug is in MethodCallExprContext, the method resolveMethodTypeParameters doesn't handle varargs properly I think. I tried to fix it in #3194 by reusing some other code that resolves type parameters as well, but now some other tests fail. I'll try to look into this

@deadlocklogic
Copy link
Contributor

Yes as I remember correctly, the problem is exclusively when it tries to solve the usage of a MethodCallExprContext with a scope, otherwise the behavior is correct. So any calls to generic methods in outer classes will not be inferred correctly. I tried to create a patch but there is absolutely no documentation on any private methods called which is kinda frustrating and time consuming. So I have to wait a bit if someone more familiar on the subject before investigating further. Between many improvements needeed to the symbolsolver, documentation comes in first places.

@jlerbsc
Copy link
Collaborator

jlerbsc commented Dec 6, 2022

This issue is corrected in the current snapshot release.

@jlerbsc jlerbsc closed this as completed Dec 6, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
5 participants