mirror of
https://github.com/colbymchenry/codegraph.git
synced 2026-10-02 18:02:49 +08:00
Colby McHenryandClaude Opus 4.7
ef29de4fd2
A Maven multi-module project where `dao/converter/FooConverter` and `service/converter/FooConverter` both expose a `convert` method used to resolve by file-path proximity — picking whichever class was closer to the caller, which is wrong any time the caller lives in an equidistant cross-cutting module. `extractImportMappings` had no Java branch at all, so the FQN signal Java imports carry — `import com.example.dao.converter.FooConverter;` — was thrown away. - `extractJavaImports` parses regular and `import static` directives; wildcard imports (`*`) are intentionally skipped. - `resolveViaImport` has a new Java/Kotlin cross-file branch that converts the imported FQN to a file-path suffix (`com/example/dao/converter/FooConverter.java`, or `.kt`) and resolves the symbol against the file whose path matches by suffix. - For the field-receiver pattern (`@Autowired private FooConverter fooConverter; fooConverter.convert(...)` — Spring's typical shape), `matchMethodCall` now looks up the receiver's inferred type in the caller file's imports and threads the resulting FQN through to `resolveMethodOnType`. When two `FooConverter::convert` candidates exist, the import — not iteration order — picks the right one. Validated end-to-end with a synthetic 3-module repro: import com.example.dao.converter.FooConverter; -> dao convert import com.example.service.converter.FooConverter; -> service convert Same field declaration, same call site, swapping only the import swaps the resolved target. spring-petclinic (47 .java files, single-module so no same-name collisions): +15 newly import-resolved edges, +2 references, no regression in calls / imports / extends / instantiates. Closes #314. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>