-
Notifications
You must be signed in to change notification settings - Fork 13.4k
false positive implied_bounds_entailment lint #108544
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
🤦 I think this is due to us preferring param-env candidates for |
So the issue here is that We try to prove that in the hybrid param-env of the impl's WC + trait method's WC, being Due to some frustrating precedence rules around candidate assembly in the trait solver, we try to match That requires us to prove |
I wonder if we could get away with not checking |
WG-prioritization assigning priority (Zulip discussion). @rustbot label -I-prioritize +P-medium |
Been thinking about this a little bit. One thought I had was to check that the impl method is WF given only the trait method, but I think that would break this example: pub trait Trait<'a, 'b> {
fn method(self, _: &'static &'static ())
where
'a: 'b;
}
impl<'a> Trait<'a, 'static> for () {
fn method(self, _: &'static &'a ()) {}
}
This is annoying difficult, because it's not straightforward to get "just the implied lifetime bounds" of a type. I'm playing around with using |
Remove manual WF hack We do not need this hack anymore since we fixed the candidate selection problems with `Sized` bounds. We prefer built-in sized bounds now since rust-lang#138176, which fixes the only regression this hack was intended to fix. While this theoretically is broken for some code, for example, when there a param-env bound that shadows an impl or built-in trait, we don't see it in practice and IMO it's not worth the burden of having to maintain this wart in `compare_method_predicate_entailment`. The code that regresses is, for example: ```rust trait Bar<'a> {} trait Foo<'a, T> { fn method(&self) where Self: Bar<'a>; } struct W<'a, T>(&'a T) where Self: Bar<'a>; impl<'a, 'b, T> Bar<'a> for W<'b, T> {} impl<'a, 'b, T> Foo<'a, T> for W<'b, T> { fn method(&self) {} } ``` Specifically, I don't believe this is really going to be encountered in practice. For this to fail, there must be a where clause in the *trait method* that would shadow an impl or built-in (non-`Sized`) candidate in the trait, and this shadowing would need to be encountered when solving a nested WF goal from the impl self type. See rust-lang#108544 for the original regression. Crater run is clean! r? lcnr
Uh oh!
There was an error while loading. Please reload this page.
The lint is triggered by the following code (from #108345, cc @EqualMa) :
In the environment
<'a> where Cow<'a, str>: Sized
, the typeOption<Cow<'static, str>>
surprisingly requires'a == 'static
for well-formedness (see #108345 (comment)), but this constraint is not used in implied bounds, so I believe it can't be exploited for unsoundness.The lint was upgraded to deny-by-default in the current beta (1.68.0-beta.5 2023-02-15 003b6f2). So this counts as regression?
cc @compiler-errors.
@rustbot label C-bug T-types T-compiler regression-from-stable-to-beta
The text was updated successfully, but these errors were encountered: