Make sure that some stdlib method signatures aren't accidental refinements

[compiler-errors]

In the process of implementing https://rust-lang.github.io/rfcs/3245-refined-impls.html, I found a bunch of stdlib implementations that accidentally "refined" their method signatures by dropping (unnecessary) bounds.

This isn't currently a problem, but may become one if/when method signature refining is stabilized in the future. Shouldn't hurt to make these signatures a bit more accurate anyways.

NOTE (just to be clear lol): This does not affect behavior at all, since we don't actually take advantage of refined implementations yet!

[rustbot]

r? @cuviper

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

[rustbot]

Hey! It looks like you've submitted a new PR for the library teams!

If this PR contains changes to any rust-lang/rust public library APIs then please comment with @rustbot label +T-libs-api -T-libs to tag it appropriately. If this PR contains changes to any unstable APIs please edit the PR description to add a link to the relevant API Change Proposal or create one if you haven't already. If you're unsure where your change falls no worries, just leave it as is and the reviewer will take a look and make a decision to forward on if necessary.

Examples of T-libs-api changes:

• Stabilizing library features
• Introducing insta-stable changes such as new implementations of existing stable traits on existing stable types
• Introducing new or changing existing unstable library APIs (excluding permanently unstable features / features without a tracking issue)
• Changing public documentation in ways that create new stability guarantees
• Changing observable runtime behavior of library APIs

[cuviper]

@bors r+ rollup

[bors]

📌 Commit 33871c9 has been approved by cuviper

It is now in the queue for this repository.

[Mark-Simulacrum]

Can we add a lint for std/core to use to prevent this by default? (IIRC, there was some discussion of not implicitly refining anyway, so maybe that's the plan still).

[compiler-errors]

@Mark-Simulacrum: Yeah, that'll eventually come around, but I've gotta work out some problems with lifetime false positives first