Repository navigation
fix(move-method): keep static utilities out of data classes and reversed dependencies (#3830) - #4156
Aman-goel-04 wants to merge 1 commit into
Conversation
|
🔍 2 things to check
Doc drift
🧾 Evidence: 1 to look at, 6 not known
👀 Suggested reviewers @RaghavChamadiya AI review is paused: this repository reached its monthly spending limit. Bot settings 📊 See the full report for this PR Settings and updatesUpdated 2026-10-21 11:22 UTC, since the last push: health 7.3 to 7.2 |
fbd0165 to
887e976
Compare
887e976 to
046c97d
Compare
|
@RaghavChamadiya, rebased this one too. Please review and lmk if any changes need to be made. |
Summary
staticnow reaches the method's graph node (modifiers), and Kotlinobject/companion objectfunctions are markedstaticby the parser.PARSER_SCHEMA_VERSIONis bumped to 9 so stale parse caches are rebuilt.MoveMethodDetectorno longer moves a static method into a class when every target member it calls is an accessor (getX/isX/setX, or a record component). Such a class is a data holder, and its getters are the method's inputs, not envy.MoveMethodDetectoralso refuses a move that would reverse a dependency on Java and Kotlin. If the method calls something outside the target and the target's file can't see it (no import, different package), the target would have to depend on the method's home.Related Issues
Fixes #3830
Test Plan
pytest):test_refactoring_move_method.py,test_misc.pyandtest_lang_samples_golden.py(89 passed)ruff check .)npm run build) (if frontend changes); n/a, no frontend changesVerification notes:
ReleaseKeyGenerator.generateReleaseKey→Namespace) printed a plan onmainand now prints none. A from-source test builds the issue's three-file fixture and covers it.validate/apply/mergeon a same-package class still moves.test_java_envy_control_still_firesand the Python@staticmethodbehaviour are unchanged.golden/java.jsonwas regenerated. The diff is purely addedmodifiers, and the Kotlin golden is unchanged.Checklist
move_method.pyand thePARSER_SCHEMA_VERSIONnotes