Remove unnecessary into conversions

[estebank]

"identity" .into() calls where the base's type isn't changed is a future compatibility foot-gun (like the issue we had with time a few months ago) as new impl Into blocks can cause previously compiling code to start failing. I don't foresee these ones in particular causing problems anytime soon, but I noticed them and might as well clean them up as a drive-by.

[rustbot]

r? @ehuss

rustbot has assigned @ehuss.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

[estebank]

I noticed these while working on rust-lang/rust#129249. I am not confident that there's no platform specific shenanigans that make these .into() calls necessary, like they it is for:

error: this conversion is useless `u64` to `u64`
   --> src/tools/cargo/src/cargo/core/shell.rs:611:49
    |
611 |             if libc::ioctl(libc::STDERR_FILENO, libc::TIOCGWINSZ.into(), &mut winsize) < 0 {
    |
    = note: `#[deny(self_type_conversion)]` on by default

I am working on correctly handling that case (it shouldn't warn at all), but in the other two cases it does seem like the lint caught real cases of this.

[weihanglo]

Thanks Esteban. Just want to confirm this doesn't really block rust-lang/rust#129249, right? I am collectin data for cargo-as-subtree in rust-lang/rust and wonder how painful it is not.

[weihanglo]

Thanks Esteban. Just want to confirm this doesn't really block rust-lang/rust#129249, right? I am collectin data for cargo-as-subtree in rust-lang/rust and wonder how painful it is not.

[estebank]

@weihanglo it doesn't block it, I worked around it on that PR for now (right now I only care about getting to the point of being able to run crater), but will become a nuisance at an indeterminate time in the future. I'm confident this can just ride the train without it becoming an issue for me (given my current speed on finishing that PR). Thanks for the concern! The PR in the end might not be landed (I'd push the new logic to clippy), or might be allow-by-default. Either way it wouldn't block progress for these to be present in our tooling. I just wanted to clean up some of the things I was seeing.