Lower the priority of unstable methods when picking a candidate.

[kennytm]

Previously, when searching for the impl of a method, we do not consider the stability of the impl. This leads to lots of insta-inference-regressions due to method ambiguity when a popular name is chosen. This has happened multiple times in Rust's history e.g.

• f64::from_bitsTracking issue for float_bits_conv feature #40470
• Ord::{min, max}Add max and min to Ord #42496
• Ord::clampTracking issue for clamp RFC #44095 (eventually got reverted due to these breakages)
• Iterator::flattenAdd Iterator::flatten #48115 (recently added)

This PR changes the probing order so that unstable items are considered last. If a stable item is found, the unstable items will not be considered (but a future-incompatible warning will still be emitted), thus allowing stable code continue to function without using qualified names.

Once the unstable feature is stabilized, the ambiguity error will still be emitted, but the user can also use newly stable std methods, while the current situation is that downstream user is forced to update the code without any immediate benefit.

(I hope that we could bring back Ord::clamp if this PR is merged.)

[rust-highfive]

r? @petrochenkov

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

[Mark-Simulacrum]

I think something along these lines is a good idea, and I especially like how it moves breakage considerations mostly to stabilization PRs where we can better evaluate the relative worth of a given feature compared to the breakage it could cause.

[bluss]

That's a fantastic idea. If you do this, you can have all the best parts of itertools 😄 and I don't mind.

[petrochenkov]

Previous iteration rust-lang/rfcs#1321
cc @rust-lang/lang

[petrochenkov]

This is a big decision.
r? @nikomatsakis

[kennytm]

(Note: the CI error is due to tcx.visibility() returning Public for the trait core::iter_private::TrustedRandomAccess.)

(Edit: Bypassed by treating unmarked APIs as stable.)

[clarfonthey]

Another thing to consider is that people could use the semver trick to hot-swap inherent methods and types with ones from the standard library once they've stabilised.

[kennytm]

Thanks for the pointer @petrochenkov :)

I’ve checked RFC 1321, this PR is slightly different from the RFC that unstable items are still considered (instead of completely hidden) but only with lowest priority. This corresponds to the “weak” alternative in the RFC:

Unstable items could instead be considered "weak", where external items can override them when there are conflicts, but would otherwise behave as they currently do.

The reason of closing the RFC were that:

1. Implemention subtleties, where stability checking 2 years ago was a mess and consequence of messing up the type checker would be huge. In this PR I reused the existing TyCtxt::check_stability function which should reduce problems due to implementation differences, though I do agree that its interaction with item privacy is still less than ideal. The change in the type-checker side seems straightforward enough that won’t cause big problems.

2. We can learn about conflicting names early. As mentioned in the RFC, we could add a future-compatibility lint if we want it, but I don’t think a hard error is the correct response. Basically what Unstable visibility RFC rfcs#1321 (comment) said.

[aturon]

Thanks for this PR!

I don't have time to leave an in-depth comment right now, but yes the major problem with an approach like this is that, in some sense, it defeats the purpose of nightly for testing; we want to know about these conflicts.

That said, I agree that doing this via a warning instead gives the best of all worlds. @nikomatsakis said something similar on the original thread, and also pointed out how difficult it may be to get this right. I'll let him comment on the current state of affairs.

[bors]

☔ The latest upstream changes (presumably #48615) made this pull request unmergeable. Please resolve the merge conflicts.

[bors]

💡 This pull request was already approved, no need to approve it again.

• There's another pull request that is currently being tested, blocking this pull request: Rollup of 15 pull requests #49308

[bors]

📌 Commit 27f92ef has been approved by nikomatsakis

[SimonSapin]

@kennytm That explains why it so in the current implementation, but as a compiler user it still seems wrong to me to warn about potential conflicts with traits that would actually not conflict because they are not in scope.

[bors]

☔ The latest upstream changes (presumably #49308) made this pull request unmergeable. Please resolve the merge conflicts.

[kennytm]

@SimonSapin the scope problem only affects suggestions. If the code is real, the out-of-scope traits won't be considered and thus won't have any spurious warnings. The last commit also disabled the warnings if the probe is used for suggestions (the cause of all spurious warnings so far).

@bors r=nikomatsakis

(Renamed "epoch" to "edition".)

[bors]

📌 Commit 17cc3d7 has been approved by nikomatsakis

[bors]

⌛ Testing commit 17cc3d7 with merge a0b0f5f...

[bors]

☀️ Test successful - status-appveyor, status-travis
Approved by: nikomatsakis
Pushing a0b0f5f to master...