Apply unused_qualifications lint

[EdJoPaTo]

Objective

Fixes #14782

Solution

Enable the lint and fix all upcoming hints (--fix). Also tried to figure out the false-positive (see review comment). Maybe split this PR up into multiple parts where only the last one enables the lint, so some can already be merged resulting in less many files touched / less potential for merge conflicts?

Currently, there are some cases where it might be easier to read the code with the qualifier, so perhaps remove the import of it and adapt its cases? In the current stage it's just a plain adoption of the suggestions in order to have a base to discuss.

Testing

cargo clippy and cargo run -p ci are happy.

[EdJoPaTo]

Enabling the lint marks the following as to be improved but applying the suggestion (like --fix does) doesn't work. Also, I don't know how to ignore the lint in the proc_macro without #![allow for the whole module.

bevy/crates/bevy_reflect/src/impls/std.rs

Lines 1468 to 1482 in 75738ed

	impl_reflect! {
	#[type_path = "core::option"]
	enum Option<T> {
	None,
	Some(T),
	}
	}
	impl_reflect! {
	#[type_path = "core::result"]
	enum Result<T, E> {
	Ok(T),
	Err(E),
	}
	}

I neither don't fully understand the actual root cause of the error (as I don't really know what the proc_macro is doing here, not familiar with the code) nor know where to report this false-positive correctly to the Rust devs. As it's not a clippy lint not the clippy repo. Maybe directly in the rust repo as it's a false-positive there?

How should we proceed with this?

[alice-i-cecile]

I'm okay proceeding with this workaround, but we should open an issue for it (and link the issue in the source). Others may know better.

[EdJoPaTo]

Yes, I agree, there should be an issue, and it should be linked in the source next to the workaround.

For opening an issue there should be a somewhat minimal reproducible example. And I seem to understand too little to reduce this issue in some ways.
At the current state I don't feel confident in opening an issue about something when I can't even create a more minimal example of it.

[EdJoPaTo]

I suspect its related: rust-lang/rust#122519

One way of handling this might be to use explicit paths (::core instead of core) but I'm not sure how to do that here as the macro should handle that. Another suggestion might be to add the #[allow into the proc_macro generated code, but I don't know where to add that best. So I can't really test if it's really related to the linked issue.

[github-actions]

Your PR increases Bevy Minimum Supported Rust Version. Please update the rust-version field in the root Cargo.toml file.

[alice-i-cecile]

Very nice diff :) I like it!

[TrialDragon]

Overall LGTM, just one issue with a, seeming, false positive.

[TrialDragon]

This one is a false positive I think; core::mem isn't imported here as far as I know, so this needs qualification, or to be pulled in in the use statements. It's why the CI failed.

[EdJoPaTo]

The question is… why? Not only the std prelude, also the core prelude include align_of per default and the stable (non-MSRV) checks do not notice this. What's different between MSRV and stable? I highly doubt that the prelude changed between 1.79 which is the current bevy MSRV and 1.80 which is the current stable, so the error must be somewhere else.

[EdJoPaTo]

Actually, 1.80 adds align_of to the prelude. I wouldn't have expected such a change and expected it to be tied to an edition. Which isn't the case.

[EdJoPaTo]

I added them explicitly to the use statements in 40237e1 (and plan on open an issue about this in the rust repo). Interestingly unused_imports (warn by default) doesn't seem to care about this on 1.80.

[EdJoPaTo]

rust-lang/rust#129306