-
Notifications
You must be signed in to change notification settings - Fork 12.9k
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
Test that we require implementing trait items whose bounds don't hold in the current impl #112929
Test that we require implementing trait items whose bounds don't hold in the current impl #112929
Conversation
@@ -805,7 +805,19 @@ fn check_impl_items_against_trait<'tcx>( | |||
.is_some_and(|node_item| node_item.item.defaultness(tcx).has_value()); | |||
|
|||
if !is_implemented && tcx.defaultness(impl_id).is_final() { | |||
missing_items.push(tcx.associated_item(trait_item_id)); | |||
let infcx = tcx.infer_ctxt().build(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This probably should use intercrate mode - #20021 (comment)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's necessary, but not sufficient. If there are no impls at all for a foreign trait, we'll still error. If we wanted to do this, it could get ugly, because we'd need to invoke some of coherence ourselves or sth (making sure either the type or the trait is local).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
erroring even when there are no impls for a foreign trait seems like correct behaviour to me, downstream crates could add impls for the foreign trait for a type they declare
This comment has been minimized.
This comment has been minimized.
this is probably very very unsound right now, two things: You need to do this in intercrate mode, the following should fail to compile: // crate a
trait Other {}
trait Trait { fn foo() where Self: Other; }
// crate b
// `u8: Other` happens to not hold righ tnow
impl Trait for u8 {} or else adding a Second you also cannot be using params here trait Trait<T> { fn foo() where T: Clone }
impl<T> Trait<T> {} this shouldn't compile but will if you are attempting to prove |
I don't think we should do this without the new solver to be honest, the ideal impl here is probably to use a list of infer vars as the substs for the impl and paramenv, supporting infer vars in the paramenv in the old solver seems like a large change so not something we should do. An easier thing might be to only support cases where your predicates dont mention any generics which conveniently sidesteps that impl requirement. The other thing is that the current solver is not super sound with |
Yea, I don't think this is possible at present in general (see #112929 (comment)). What we could do is limit it to predicates that are for |
edb4d45
to
055ee29
Compare
This comment has been minimized.
This comment has been minimized.
055ee29
to
0ddf2f7
Compare
This comment has been minimized.
This comment has been minimized.
915cdd3
to
1715ad6
Compare
r? @compiler-errors this just now adds tests and doesn't change compiler behaviour |
1715ad6
to
f69e04f
Compare
@rustbot ready |
This comment has been minimized.
This comment has been minimized.
… of effect on impls
f69e04f
to
042f605
Compare
@bors r+ rollup (only tests) |
…iaskrgr Rollup of 7 pull requests Successful merges: - rust-lang#112670 (privacy: Type privacy lints fixes and cleanups) - rust-lang#112929 (Test that we require implementing trait items whose bounds don't hold in the current impl) - rust-lang#113054 (Make `rustc_on_unimplemented` std-agnostic) - rust-lang#113137 (don't suggest `move` for borrows that aren't closures) - rust-lang#113139 (style-guide: Clarify let-else further) - rust-lang#113140 (style-guide: Add an example of formatting a multi-line attribute) - rust-lang#113143 (style-guide: Narrow guidance about references and dereferencing) r? `@ghost` `@rustbot` modify labels: rollup
I initially tried to make most of these pass, but that's a big can of worms, so I'm just adding them as tests, considering we have no tests for these things.