extra_requirement_in_impl future-compatibility warning

[nikomatsakis]

This is the summary issue for the extra_requirement_in_impl future-compatibility warning 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?

There has been a longstanding bug in rustc (#18937) that sometimes allowed an impl
to place additional requirements on its methods above and beyond the requirements
that appear in the trait definition. For example:

trait Trait {
    fn foo<F>(&mut self, f: F)
        where F: Clone;
}

impl Trait for i32 {
    fn foo<F>(&mut self, f: F)
        where F: Clone + 'static
    {   //               ^^^^^^^ additional requirement
    }
}

This is unsound and can permit crashes and other arbitrary behavior.
The solution is usually to move the requirement into the trait definition:

trait Trait {
    fn foo<F>(&mut self, f: F)
        where F: Clone + 'static;
}

or else remove the requirement from the impl.

When will this warning become a hard error?

At the beginning of each 6-week release cycle, the Rust compiler team will review the set of outstanding future compatibility warnings and nominate some of them for Final Comment Period. Toward the end of the cycle, we will review any comments and make a final determination whether to convert the warning into a hard error or remove it entirely.

[nagisa]

There’s a desire to make this either a “lint-error” or “non-lint-warning” (can’t be disabled) for 1.16 and hard error for 1.17.

[nikomatsakis]

Discussed in compiler-team meeting and decided to move this to deny-by-default.

[Mark-Simulacrum]

This appears unrelated to metadata, untagging.

[nikomatsakis]

@rfcbot fcp close

It has been over a year since these future-compatibility warnings were issued. I move that we make this a HARD ERROR. This is a serious bug with real soundness implications and is currently set to error (deny) by default. Also, the backwards compatibility code happens to be getting in my way right now. =)

[rfcbot]

Team member @nikomatsakis has proposed to close this. The next step is review by the rest of the tagged teams:

• @Aatch
• @arielb1
• @eddyb
• @estebank
• @jseyfried
• @michaelwoerister
• @nikomatsakis
• @nrc
• @petrochenkov
• @pnkfelix

No concerns currently listed.

Once a majority of reviewers approve (and none object), 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.

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period is now complete.

[nikomatsakis]

It seems like this got done a long time ago.