diff options
| author | bors <bors@rust-lang.org> | 2018-03-24 04:43:24 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2018-03-24 04:43:24 +0000 |
| commit | a0b0f5fba5d7bf18b24d1fa0e454a4fe871fecee (patch) | |
| tree | 9369afe94bbea45db94172abd02c1acc4fb7630e /src/rustllvm/RustWrapper.cpp | |
| parent | ab0ef145ac993d01a73c1c4a5decb1f68b3aad36 (diff) | |
| parent | 17cc3d77d16e0cc3dfa1b3ee9749e2fca3ebb9e7 (diff) | |
| download | rust-a0b0f5fba5d7bf18b24d1fa0e454a4fe871fecee.tar.gz rust-a0b0f5fba5d7bf18b24d1fa0e454a4fe871fecee.zip | |
Auto merge of #48552 - kennytm:lower-unstable-priority, r=nikomatsakis
Lower the priority of unstable methods when picking a candidate.
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_bits` #40470
* `Ord::{min, max}` #42496
* `Ord::clamp` #44095 (eventually got reverted due to these breakages)
* `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.)
Diffstat (limited to 'src/rustllvm/RustWrapper.cpp')
0 files changed, 0 insertions, 0 deletions
