Tracking issue for future-incompatibility lint `unstable_name_collisions`

[kennytm]

This is the summary issue for the unstable_name_collisions future-incompatibility lint and other related errors. The goal of this page is describe why this change was made and how you can fix code that is affected by it. It also provides a place to ask questions or register a complaint if you feel the change should not be made. For more information on the policy around future-compatibility warnings, see our breaking change policy guidelines.

What is the warning for?

Rust's standard library is evolving, and will sometimes add new functions we found useful, e.g. Ord::clamp or Iterator::flatten. Unfortunately, there will often be popular third-party packages already implemented the same function with the same name. The compiler, when seeing the name flatten, cannot decide whether you want the one from the standard library or the third-party library, and gives up with the multiple applicable items in scope error.

As an inference breakage canary, the compiler will emit a warning whenever it detected a name conflict with an unstable standard library function.

extern crate itertools;
use itertools::Itertools;

fn main() {
    println!(
        "{:?}",
        [[1, 2], [3, 4]].iter().flatten().collect::<Vec<_>>()
        //~^ WARN a method with this name will be added to the standard library in the future
    );
}

To stop this warning and the future hard error, you could use fully-qualified name to explicitly tell the compiler to use the third-party function:

extern crate itertools;
use itertools::Itertools;

fn main() {
    println!(
        "{:?}",
        Itertools::flatten([[1, 2], [3, 4]].iter()).collect::<Vec<_>>()
//      ^~~~~~~~~~~~~~~~~~~.......................~
//      explicitly use the `flatten` method from the `Itertools` trait.
    );
}

When will this warning become a hard error?

This warning will be emitted for every unstable library feature having name conflicts. When a particular library feature is stabilized, this name conflict will cause a hard error.

Please follow the tracking issue for each library feature for their stabilization progress. Some current unstable method which is known to cause conflict in the wild are:

• Vec::try_reserve — Tracking issue for try_reserve: RFC 2116 fallible collection allocation #48043
• Ord::clamp — Tracking issue for clamp RFC #44095