java type inference chain method calls and field access

[HRV1527]

@vitali87
I had a question regarding the java type inference that it currently does not handle java chain method calls and field access such as :

class Address {
    public String zipCode = "90210";
}

class User {
    public Address address = new Address();
}

public class Main {
    public static void main(String[] args) {
        User obj = new User();
        
        // Chained Field Access
        String zip = obj.address.zipCode;
        System.out.println("Zip: " + zip);
    }
}

class QueryBuilder {
    private String query = "SELECT * ";

    public QueryBuilder from(String table) {
        this.query += "FROM " + table;
        return this; // Returning 'this' enables the chain
    }

    public QueryBuilder where(String condition) {
        this.query += " WHERE " + condition;
        return this;
    }

    public void execute() {
        System.out.println("Executing: " + query);
    }
}

public class Main {
    public static void main(String[] args) {
        QueryBuilder obj = new QueryBuilder();

        // Chained Method Calls
        obj.from("users").where("id = 1").execute();
    }
}

class Engine {
    public void start() {
        System.out.println("Engine started!");
    }
}

class Car {
    // The field
    public Engine engine = new Engine();
}

public class Main {
    public static void main(String[] args) {
        Car obj = new Car();

        // Mixed: obj (Car) -> field (engine) -> method (start)
        obj.engine.start();
    }
}

Also in java type inference the sequence of inferencing is :

            # 2. Analyze local variable declarations in the scope
            self._analyze_java_local_variables(scope_node, local_var_types, module_qn)
            # 3. Analyze field declarations from the containing class
            self._analyze_java_class_fields(scope_node, local_var_types, module_qn)

Which I think should be:

            # 2. Analyze field declarations from the containing class
            self._analyze_java_class_fields(scope_node, local_var_types, module_qn)

            # 3. Analyze local variable declarations in the scope
            self._analyze_java_local_variables(scope_node, local_var_types, module_qn)

Parameters first (already correct)
Class fields second - Fields are declared at class level and their types are fully known without dependencies on local variables
Local variables third - Local variables can reference parameters and fields in their initializers

[vitali87]

Thanks for the detailed writeup, and sorry for the slow reply. Status on each of your three points:

Chained field access (obj.address.zipCode) and mixed chains (obj.engine.start()): fixed. Commit 7774b54 and follow-ups added recursive field-access chain inference and receiver-chain resolution, including this/super roots, inherited fields, and nested superclasses. Your exact examples are covered in codebase_rag/tests/test_java_field_access_chains.py.

Chained method calls (obj.from("users").where("id = 1").execute()): partially. Your exact snippet now produces the correct CALLS edges, but only via the unqualified-call fallback (a module-wide name scan), not by propagating the receiver's return type through the chain. If another class in scope declares a same-named method, the chain mis-binds. I've opened #1334 to track proper return-type propagation for method_invocation receivers, with a failing reproduction included. Note that hoisting each step into a local (QueryBuilder a = obj.from("users"); a.where(...)) already resolves correctly, since typed locals are handled.

Ordering of _analyze_java_local_variables vs _analyze_java_class_fields: no change needed. _analyze_java_class_fields only registers a bare field name when it isn't already present in the map, so locals keep precedence, which matches Java's shadowing semantics. Swapping the order would produce the same end state. Locals whose initializers reference fields also resolve fine, because identifier lookups go through _lookup_variable_type, which builds the full module-level type map.