Variable or FieldDeclaration is not resolved correctly when another variable with the same name is declared in the same block

[Kimmmey]

Hi, I have a problem resolving the declaration of a variable/field. In the following example, the target of the assignment in line 6 gets resolved to the VariableDeclaration in line 7 and therefore I get the wrong type and doesn't know that a is a field and not a variable.

package test;

public class Example {
    int a = 3;
    public void bla() {
        a = 7; // gets resolved to name: a type: String Declaration: begin 7,9 end 7,21
        String a = "";
        a = "test";
    }
}

Without the local variable a (lines 7-8) or by renaming it, the declaration of a(line 6) is resolved to the FieldDeclaration in line 4.

Is there a gerneral problem in this situation or is it on my end?

[jlerbsc]

Hi @Kimmmey you are right there is certainly a bug. Thank you for reporting it.

[Kimmmey]

I could be wrong, but I think the bug is already known. At least that's how I interpret the comment in com.github.javaparser.symbolsolver.javaparsermodel.contexts line 96.

Are there any plans to fix this? I don't think I'm good enough to create a patch for it.

[Kimmmey]

That was fast. Thank you.

[jlerbsc]

It was an interesting topic :-)

[Kimmmey]

Hi @jlerbsc after implementing your modified version in my project, I have still the same problem.

Here's what I noticed:

1. your added Testcase passes with version 3.24.0 as well,
2. a modified version of your Testcase (Patch: #3526__modified_Test.zip) shows, that for both AssignExpr the targets are resolved to int (3.24.0 and with pull request from above).
3. in my project I still get type String for both AssignExpr targets, (3.24.0 and with your patch) and i am not able to find the difference between the extended test case and the implementation in my project,
4. I am not completely sure, but it seems, to me, that the method StatementContext::solveSymbolAsValue(String) is not called at all (in this use case), but the method StatementContext::solveSymbol(String, boolean) is. This also seems to be the case for BlockStmtContext and ClassOrInterfaceDeclarationContext. I have no idea what the difference is between solveSymbol and solveSymbolAsValue.

If this works correctly for you, I'm probably doing something wrong. In that case, I probably need more help. :)

[jlerbsc]

I'm not sure to understand your issue because this test runs correctly in the version 3.24.2-SNAPSHOT

    @Test
    public void test3526() {
        String src = "public class Example {\n"
                + "    int a = 3;\n"
                + "    public void bla() {\n"
                + "        a = 7; // gets resolved to name: a type: String Declaration: begin 7,9 end 7,21\n"
                + "        String a = \"\";\n"
                + "        a = \"test\";\n"
                + "    }\n"
                + "}";
        ParserConfiguration configuration = new ParserConfiguration()
                .setSymbolResolver(new JavaSymbolSolver(new CombinedTypeSolver(new ReflectionTypeSolver())));
        StaticJavaParser.setConfiguration(configuration);
        CompilationUnit cu = StaticJavaParser.parse(src);
        AssignExpr expr = cu.findFirst(AssignExpr.class).get();
        ResolvedType rt = expr.calculateResolvedType();
        assertEquals("int", rt.describe());
        
        expr = cu.findAll(AssignExpr.class).get(1); // refer to a = "test"
        ResolvedType rt2 = expr.calculateResolvedType(); 
        assertEquals("java.lang.String", rt2.describe());
    }

[jlerbsc]

@Kimmmey The unit case was wrong.

[Kimmmey]

Hi @jlerbsc, I think we are talking past each other. First of all, thank you for your patient help.

After some testing I figured out what your fix does. You fixed the resolution of the Type of the AssignExpr.

My problem is, that I try to resolve the declaration of the target of the AssignExpr (I need the declaration, the Type is not enough) and therefore I didn't know that the resolution of the Type of the AssignExpr was broken too.

I pushed an extended Unit Test Kimmmey/javaparser/commit/1d5721bf4ccf5daa4b5ff834a418b1c442e2b0f4 and hope that this describes my problem clearly enough.

[jlerbsc]

Hi @Kimmmey currently there is no way to fix the bug you have identified because at this stage of the analysis JSS no longer has a reference to the node of the AST that is being analyzed. In my opinion, the only way we have to solve this problem would be to keep the reference of the node that bears the name of the variable that we are trying to solve. I'm trying to see if I can enrich the Context API to keep this reference without breaking the current behavior. It may take a while. Thank you for your patience.