feat: cross-parent module move in willRenameFiles

[enomado]

Summary

Implements the request in #8872: moving a module to a new parent — dragging a
.rs file or a module folder into a different directory — now fixes the module
tree and rewrites references, instead of leaving the code broken.

workspace/willRenameFiles previously handled only same-directory renames (#7009).
This adds the cross-parent case.

What it does

A new ide entry point Analysis::will_move_module, backed by
ide_db::rename::move_mod, produces a single SourceChange:

• mod-tree surgery — drop the old mod X; (with its trailing newline) and
  re-declare it, preserving visibility, at the end of the new parent's item list;
• reference rewrite — for each usage, splice the leading ast::Path ending at
  the module segment with the module's new absolute crate::… path, leaving any
  trailing ::Item untouched (HIR still describes the pre-move tree, so the
  old/new absolute paths are computed textually);
• super:: re-anchoring inside the moved file — a leading super run is
  rewritten to the crate::… path it denotes today, since after the move the same
  text would resolve against a different parent (self:: is left alone);
• grouped use imports — a member importing through the moved module is pulled
  out into its own use; an emptied group is replaced wholesale, otherwise moved
  members are deleted as overlap-free runs;
• cross-crate references keep the extern crate name (foo::a::m → foo::b::m),
  honouring package = "…" renames;
• mod.rs / directory modules — the same surgery generalizes; the editor moves
  the directory physically, so only text edits are emitted.

handle_will_rename_files gained a cross-parent arm that maps the destination
directory to the new parent's crate-relative module segments and routes both dropped
files and dragged folders (resolved via their mod.rs) to will_move_module.
File-system edits stay cleared — the editor owns the physical move.

Boundaries (documented in code, left to the compiler)

• macro-expanded references (edits would have to land in the macro input);
• a super::super… chain inside a child file of a moved directory module that
  climbs above the module (only the moved module's own file is re-anchored);
• pub(super) / pub(in super::x) visibility.

Tests

• will_move_module_* unit tests in ide cover each case exhaustively via
  expect_test;
• two rust-analyzer slow-tests pin the LSP wiring:
  test_will_rename_files_cross_parent (file drag) and
  test_will_rename_files_cross_parent_folder (folder drag).

Disclosure

This change was written end-to-end by an AI coding agent (Anthropic's Claude) —
it is entirely AI-generated ("vibe-coded"). A human directed the work, reviewed the
diff, and ran the tests, but did not hand-write the implementation. Flagging this
explicitly so reviewers can weigh it accordingly; happy to iterate on anything.

Closes #8872.

[rustbot]

⚠️ Warning ⚠️

• There are uncanonicalized issue links (such as #123) in the commit messages of the following commits.
  Please add the organization and repository before the issue number (like so rust-lang/rust#123) to avoid issues with subtree.
  • 1189902

[ChayimFriedman2]

This change was written end-to-end by an AI coding agent (Anthropic's Claude) —
it is entirely AI-generated ("vibe-coded"). A human directed the work, reviewed the
diff, and ran the tests, but did not hand-write the implementation.

A human reviewing the AI-generated code is not enough; said human must have the ability to fully understand the code, to the point that they could have written it themselves and only use the AI as a way to cut development time. Given that this is only your second contribution to rust-analyzer, and the first one was nowhere close to the size of this one, I heavily doubt this is the case.

Also, I suspect you also used AI to author the pull request description, and that is plain forbidden by our AI policy.

[enomado]

i need feature - i asked claude to implement this feature. you are free to play your ai-denial games. i did pr because hundreds of people did the same but as scripts.

[ChayimFriedman2]

You are, of course, free to merge and personally maintain any feature or code you want in your rust-analyzer fork, AI-generated or not. What you cannot do is asking us to merge it into the main repo. If you want your code to be merged, you need to obey our rules.

[ChayimFriedman2]

With that said: I don't want to review hundreds of unsupervised AI-generated code lines. If you confirm that you think you completely understand this patch, I'll take your word for it and review this. Otherwise, I will close this PR. Note that this PR has a lot of comments, which is typical for AI-generated code and usually not a good sign.

That is unrelated to the fact you used AI to generate the PR description. Given that you probably didn't know that is forbidden that is acceptable this time, but if you'll continue doing that we'll reach out to moderation.

[enomado]

Well. Fair enough. I'm not sure this is solid right now. I need some time