remove redundant imports

[surechen]

detects redundant imports that can be eliminated.

for #117772 :

In order to facilitate review and modification, split the checking code and removing redundant imports code into two PR.

r? @petrochenkov

[rustbot]

r? @TaKO8Ki

(rustbot has picked a reviewer for you, use r? to override)

[petrochenkov]

r=me after removing allows.
@rustbot author

[surechen]

r=me after removing allows. @rustbot author

Ok. Thank you.

[rustbot]

Some changes occurred in src/tools/rustfmt

cc @rust-lang/rustfmt

Some changes occurred in src/librustdoc/clean/types.rs

cc @camelid

Some changes occurred in compiler/rustc_codegen_cranelift

cc @bjorn3

The Miri subtree was changed

cc @rust-lang/miri

Some changes occurred to MIR optimizations

cc @rust-lang/wg-mir-opt

Some changes occurred in src/tools/clippy

cc @rust-lang/clippy

rust-analyzer is developed in its own repository. If possible, consider making this change to rust-lang/rust-analyzer instead.

cc @rust-lang/rust-analyzer

This PR changes Stable MIR

cc @oli-obk, @celinval, @spastorino, @ouz-a

Some changes might have occurred in exhaustiveness checking

cc @Nadrieril

[petrochenkov]

@bors r+

[bors]

📌 Commit 4b64fbf has been approved by petrochenkov

It is now in the queue for this repository.

[klensy]

This is only cleanup, actual implementation in other PR, why relnotes label?

[petrochenkov]

Yes, relnotes should be on #117772.

[calebcartwright]

@petrochenkov

re: #118692 (comment)

Thanks, I genuinely appreciate you not only taking the time to reply, but engaging in discussion of the topic! ❤️ 🙏

You're correct that I've expressed this sentiment before, and I've also seen it echoed/shared by other subtree maintainers elsewhere. I confess I've found it confusing and occasionally frustrating when those sentiments are outright ignored or quickly dismissed.

This is probably a topic best to continue discussing in Zulip, but suffice to say that I feel the dev guide has prescribed guidance on this topic which is often contradicted in practice, and at a minimum I think that's something which should be addressed (even if that means reversing or clarifying the language in the dev guide)

Rebasing rustfmt subtree over changes like this during update is trivial,

fwiw this is incorrect, rebasing cannot be used on the subtree pushes which is a big part of why i keep raising this issue. it does produce very real challenges for us, i promise i'm not just making noise on the basis of speculation 😅

[lnicola]

On the rust-analyzer side, I'm very worried about merging back these changes because we've had problems with git-subtree in the past, and it seems a little janky at times (it's been saying for about 6 months that it's resolving one specific conflict on every sync back). In practice, though, merging back trivial PRs like this one hasn't been an issue yet.

It does feel, however, like they're becoming more and more common lately, and it's sometimes even hard to keep with them. I understand build fixes, but doing this for cosmetic changes really feels unnecessary. Lints in particular are a bit weird -- on the RA side we're fine with the stable ones. If it's that important for rust-lang/rust to run unstable (or changed in nightly) lints against subtrees, okay, we'll handle it, but it's pretty stressful.

PS: I noticed recently that syncing back yields a ton of conflicts if the upstream (RA) has new commits. But if you do it in two steps (merge up to the version that's in downstream, then merge again with master), it's much better. Just something to keep in mind.

[calebcartwright]

Well said @lnicola

For me it's not about any one particular change in isolation, it's very much the aggregate set of changes that I find often has a compounding effect on complicating the subtree syncs and the increase in frequency of such changes. git subtree is indeed very touchy and, for whatever reason, quickly and easily gets very fussy

(edit: typo correction)

[petrochenkov]

@bors r+

[bors]

📌 Commit 40ae341 has been approved by petrochenkov

It is now in the queue for this repository.

[bors]

⌛ Testing commit 40ae341 with merge 84f6130...

[bors]

☀️ Test successful - checks-actions
Approved by: petrochenkov
Pushing 84f6130 to master...

[rust-timer]

Finished benchmarking commit (84f6130): comparison URL.

Overall result: no relevant changes - no action needed

@rustbot label: -perf-regression

Instruction count

This benchmark run did not return any relevant results for this metric.

Max RSS (memory usage)

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	3.9%	[3.7%, 4.0%]	2
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Cycles

Results

This is a less reliable metric that may be of interest but was not used to determine the overall result at the top of this comment.

	mean	range	count
Regressions ❌ (primary)	-	-	0
Regressions ❌ (secondary)	8.4%	[5.4%, 11.3%]	6
Improvements ✅ (primary)	-	-	0
Improvements ✅ (secondary)	-	-	0
All ❌✅ (primary)	-	-	0

Binary size

This benchmark run did not return any relevant results for this metric.

Bootstrap: 669.935s -> 668.621s (-0.20%)
Artifact size: 314.15 MiB -> 314.12 MiB (-0.01%)