r? @ibraheemdev

rustbot has assigned @ibraheemdev.
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

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

r? libs-api to confirm that this is fine to merge with nightly breakage due to the conflicts.

@rfcbot fcp merge

Even though this is an unstable addition, let me run this by the team to assess whether we want to take this step now. This PR causes new warnings in code that uses itertools::Itertools::contains (which is one of the more widely used itertools extension trait methods).

Unfortunately the warning is 100% spurious, because we have no intention of stabilizing Iterator::contains in a way that would cause the breakage that it warns about. With #89151, code like the following from rust-analyzer will retain its current behavior because Iterator is a supertrait of Itertools so the supertrait method will be shadowed instead of ambiguous.

If we merge this as-is, a lot of people will get warnings and uselessly rewrite their code.

warning: a method with this name may be added to the standard library in the future
 --> crates/ide-assists/src/handlers/convert_bool_to_enum.rs:381:48
 |
381 | if !bin_expr.lhs()?.syntax().descendants().contains(name.syntax()) {
 | ^^^^^^^^
 |
 = warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior!
 = note: for more information, see issue #48919 <https://github.com/rust-lang/rust/issues/48919>
 = help: call with fully qualified syntax `itertools::Itertools::contains(...)` to keep using the current method
 = note: `#[warn(unstable_name_collisions)]` on by default
help: add `#![feature(iter_contains)]` to the crate attributes to enable `std::iter::Iterator::contains`
 --> crates/ide-assists/src/lib.rs:63:1
 |
63 + #![feature(iter_contains)]
 |
warning: a method with this name may be added to the standard library in the future
 --> crates/ide-assists/src/handlers/convert_bool_to_enum.rs:447:41
 |
447 | if !receiver.syntax().descendants().contains(name.syntax()) {
 | ^^^^^^^^
 |
 = warning: once this associated item is added to the standard library, the ambiguity may cause an error or change in behavior!
 = note: for more information, see issue #48919 <https://github.com/rust-lang/rust/issues/48919>
 = help: call with fully qualified syntax `itertools::Itertools::contains(...)` to keep using the current method
help: add `#![feature(iter_contains)]` to the crate attributes to enable `std::iter::Iterator::contains`
 --> crates/ide-assists/src/lib.rs:63:1
 |
63 + #![feature(iter_contains)]
 |

Team member @dtolnay has proposed to merge this. The next step is review by the rest of the tagged team members:

• @Amanieu
• @BurntSushi
• @dtolnay
• @joshtriplett
• @m-ou-se

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

I think I would prefer to block this PR on not necessarily stabilizing #89151, but just a compiler fix that prevents the unstable_name_collisions warning in the case of supertrait colliding methods.

I'm also happy to block this on #89151.