Repository navigation
Description
This is the summary issue for the WHERE_CLAUSES_OBJECT_SAFETY 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 (https://github.com/rust-lang/rfcs/blob/master/text/1122-language-semver.md).
What is the warning for?
As was discovered in #50781 a combination of implementing a trait directly for a dyn type and where clauses involving Self can punch a hole in our dyn-capability rules rules. See the minimization:
trait Trait {}
trait X { fn foo(&self) where Self: Trait; }
impl X for () { fn foo(&self) {} }
impl Trait for dyn X {}
// Segfault at opt-level 0, SIGILL otherwise.
pub fn main() { <dyn X as X>::foo(&()); }The fix applied in #50966 is to tighten the dyn-capability rules to make X not dyn-capable in this case, in general making any trait that contains Self in where clauses not dyn-capable, much like we disallow Self in arguments or return type. Few root regressions appeared in the crater run and those were fixable, though some crates being unmaintained complicates things.
However that fix is heavy handed and disallows things we actually wish to support, still we went ahead with the warning as a stop gap while we look for a better, more targeted fix. The original issue contains some discussion of alternative fixes. With tight chalk integration, we could do some clever things.
Other alternatives discussed for the short-term:
- Checking from an
impl Foo for dyn Bar + ..whether that impl is causing trouble. This seems to be a dead end because it's hard to tell whichdyntypes are targeted by a blanket impl such asimpl<U: ?Sized + Bounds> Trait for U. - Checking the cast sites with a rule like "if
dyn Foo: Traitthen to castTintodyn Foowe require thatT: Traitmust also hold", probably for everyTraitsuch thatSelf: Traitappears in where clauses in the traits methods. This would alleviate the warning forSelf: Traitwhere clauses. This may be practical to implement now, but seems subtle, we'd need to give it more thought.
When will this warning become a hard error?
Hopefully we will develop a finer-grained rule and this warning will never be an error.
How to fix this?
Either drop the where clause or stop using dyn types with the affected trait. If this is not viable, that's probably ok, it's very unlikely that your code is actually unsound. But please do report your case here so take we may take it into consideration and see how to better support it!
Metadata
Metadata
Assignees
Labels
Type
Projects
- StatusShow more project fieldsIdea
Activity
nikomatsakis commentedon Jun 25, 2018
To clarify: we are specifically interested in getting feedback on places where this lint causes you issues, since that will help us to judge how well more precise fixes would work.
cramertj commentedon Jun 27, 2018
This caused a future-compat warning in the upcoming
futures0.3 crate. Minimized example:The error:
It seems like it should be possible to permit calls to
poll_unpinin cases whereSelfis adyn Traittype whereTrait: Unpin.nikomatsakis commentedon Jun 28, 2018
Thanks @cramertj -- that falls pretty squarely into the rules we had in mind! Let's discuss the details of those rules in #50781 I guess, I want to try and "re-sync" (but I guess I'd rather keep this thread for people to report issues).
But just to summarize, the rule we had in mind is roughly this:
Traithas a methodmethodwith a where-clausewhere Self: XXXdyn Trait: XXXcannot be proventrait Trait: XXX-- we could perhaps try to distinguish those cases; in Chalk terms,XXXwould be an implied bound ofTraitThat applies to your example, I believe, since
dyn Future: Unpindoes not hold.This is a kind of generalization of the rule around
where Self: Sized-- except that, in that case, we know thatdyn Trait: Sizedcould never be proven, and hence we can suspend the where-clause requirements entirely.locka99 commentedon Jul 13, 2018
For anyone reading this, I got the warning/error on a trait that was like this:
In my case I was able to make the problem go away by requiring the thing implementing Config to also implement serde::Serialize:
emilio commentedon Jul 30, 2018
This broke bindgen:
This is on this bindgen commit fwiw: rust-lang/rust-bindgen@29dad40
Require TemplateParameters to be Sized.
Emerentius commentedon Aug 1, 2018
I have an extension trait that was never supposed to be made into an object which triggers this. It only exists to add a few methods.
I could limit the implementors to just
[T]down fromT: AsRef<[T]>which would stop the lint from firing (and also be a better design), but it would also make the dyn capability pointless as there's only one type that could be made into the object.I like this as a lint but the
it will become a hard error in a future release!part of the error message should go. Not all traits require dyn capability.Edit: In fact, the lint is a false positive. The trait isn't dyn capable already because it contains generic functions.
alecmocatta commentedon Aug 3, 2018
I bumped into this upcasting boxed trait objects with marker traits. There may be a way to do this safely that doesn't fall foul of this lint?
(Playground)
passcod commentedon Aug 24, 2018
This warns on
AnyMap, but I don't understand enough to really figure out what's going on and how it should be fixed:rodrimati1992 commentedon Sep 16, 2018
I have an extension trait that i want to be usable with ?Sized types (including str) where this is causing a problem.
This is the reduced version of the trait:
With the previous 2 methods I get this somewhat confusing pair of warning and error :
It seems to me that if it knows that it can't be turned into a trait object because it has a generic method,
then it should not warn because of the Self type in the where clause of format_debug.
20 remaining items
RalfJung commentedon Jan 8, 2023
Well, we need to change something to fix #50781. Have there been other plausible proposals?
dtolnay commentedon Jan 8, 2023
Yes I tried to imply a counterproposal in the "2 reasons" in my comment.
Rollup merge of rust-lang#107082 - dtolnay:autotraits, r=lcnr
Rollup merge of rust-lang#107082 - dtolnay:autotraits, r=lcnr
[-]`where_clauses_object_safety` future compatibility lint[/-][+]Tracking issue for future-incompatibility lint `where_clauses_object_safety`[/+]fmease commentedon Sep 14, 2024
This lint is no longer emitted by the compiler.
It has been upgraded to a hard error.
Closing as fixed by #125380.