Recent PRs break lots of nightly builds

[gilescope]

I'm seeing most of the nightly project broken at the moment. It's either due to #88581 or due to this one:

   |
22 |             .intersperse(self.separate)
   |              ^^^^^^^^^^^ multiple `intersperse` found
   |
   = note: candidate #1 is defined in an impl of the trait `Iterator` for the type `std::iter::Map<I, F>`
   = note: candidate #2 is defined in an impl of the trait `Itertools` for the type `T`
help: disambiguate the associated function for candidate #1
   |
19 ~         Iterator::intersperse(self.items
20 +             .iter()
21 +             .map(|c| c.min_width()), self.separate)
   |
help: disambiguate the associated function for candidate #2
   |
19 ~         Itertools::intersperse(self.items
20 +             .iter()
21 +             .map(|c| c.min_width()), self.separate)
   |

For example it breaks every branch of every git repo that uses:
prost-derive-0.7.0/
lalrpop-0.18.1
I suspect there's a few others, but prost is used in lots of places (as is bigint).

We need to somehow be kinder to the nightly ecosystem somehow with large scale backwardly incompatible breaking changes. Do we have an idea what percentage of projects still compile with latest nightly? I think it's a heavy dip at the moment.

[the8472]

This is allowed under RFC 1105 rules and I believe the libs team is and was aware of the conflicts that this would create when promoting an itertools method to std, it's not the first time this happened after all.
There just isn't a solution to this problem yet other than disambiguating the method call.

Regarding #88581, I thought there was some adjustment in method resolution (#48552) that skipped unstable methods when the feature isn't activated and a stable one of the same name is in scope. Does this not work here? Or is this due to uses of deny(warnings)?

[mohe2015]

What about notifying the most popular crates in advance and waiting a week or so next time? The issue with num-bigint seems to have been known before the merge.

[CryZe]

@the8472 The method actually got stabilized on nightly in #88548. So no unstable methods are being skipped here.

[the8472]

@CryZe that applies to intersperse but not to int_roundings. @gilescope is talking about two different cases, one stabilization and one unstable addition.

[lukaslueg]

This is mainly because #88548 breaks every user of itertools::intersperse(), which is defined in the popular itertools-crate.

[ehuss]

Regarding #88581, I thought there was some adjustment in method resolution (#48552) that skipped unstable methods when the feature isn't activated and a stable one of the same name is in scope. Does this not work here?

The reason the unstable-skip didn't work is because method resolution goes in a series of steps (T, then &T, then &mut T, etc.). The way the code is written, the unstable skip only works within a single step (when the receivers are the same between the unstable method and the other method), it doesn't seem to work across steps. I'm not sure how feasible it would be to change that, I didn't see any discussion on #48552 about the potential of having different receivers.

[Mark-Simulacrum]

Closing since this is separately tracked elsewhere (e.g., in tracking issues for the respective features).