-
Notifications
You must be signed in to change notification settings - Fork 1.6k
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
Fix rust-lang/rust#107877, etc. #10403
Conversation
With the just pushed commit, I revised the approach. 😬 I'm sorry for the moving target, but I think you'll agree the new approach is better. |
clippy_lints/src/dereference.rs
Outdated
// avoid hitting this `span_bug`: | ||
// /~https://github.com/rust-lang/rust/blob/695072daa6cc04045f2aa79d751d884ad5263080/compiler/rustc_trait_selection/src/traits/query/normalize.rs#L272-L275 | ||
// See: /~https://github.com/rust-lang/rust/issues/107877 | ||
if implements_trait(cx, new_ty, assoc_item.container_id(cx.tcx), List::empty()) |
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.
Shouldn't this pass the substitutions needed for the trait, rather than just an empty list?
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.
Yes, but do we have a way of knowing what those could could/should be?
I was under the impression we were making a best effort guess of "no parameters needed."
Maybe I'm misunderstanding, but I thought that's what was happening with []
here:
rust-clippy/clippy_lints/src/dereference.rs
Lines 1362 to 1363 in a2c2b27
let projection = cx.tcx | |
.mk_projection(assoc_item.def_id, cx.tcx.mk_substs_trait(new_ty, [])); |
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.
The parameters are stored in the projection predicate. You'd need to replace the self type but otherwise they should be correct. This is probably the reason for the ambiguity error in the first place. If both Foo<X>
and Foo<Y>
are implemented then Foo<_>::Assoc
could refer to either.
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.
I think implements_trait
returns false in this case which hides the error.
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.
It looks like your analysis was spot on.
Thank you. @bors r+ |
☀️ Test successful - checks-action_dev_test, checks-action_remark_test, checks-action_test |
[beta] Clippy: backport optimization and ICE fixes The first commit optimizes a lint, that runs noticeably slow and is a perf issue. See rust-lang/rust-clippy#10533 The second commit fixes an ICE that occurred when running Clippy on `gitoxide` besides others. Since this is a rather popular crate, we want to fix this rather sooner than later. See rust-lang/rust-clippy#10403 --- Both commits are already on `master` and deployed on `nightly`.
Fix #10009
Fix #10387
Fix rust-lang/rust#107877
The fix is to verify that the associated item's trait is implemented before trying to project the item's type.
r? @Jarcho
changelog: ICE: [
needless_borrow
]: No longer panics on ambiguous projections#10403