-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Allow impl on projection #107263
base: master
Are you sure you want to change the base?
Allow impl on projection #107263
Conversation
This comment has been minimized.
This comment has been minimized.
6d33252
to
075fb58
Compare
Fixed the privacy bug. With this it should be complete. |
075fb58
to
836bf7b
Compare
I added another UI tests for implementations on foreign types (not primitive types). |
|
||
pub struct S; | ||
|
||
impl <S as Identity>::Identity { |
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.
Sorry, this is what I wanted to mention. I'm not sure if we want to be able to normalize impl headers when considering inherent impls.
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 also something I wondered but after talking with @oli-obk, they seemed to think it was ok so I made this PR. I think it'll require an FCP in any case so you can see with your team whether or not it's something you want.
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.
My words were "why should we not allow it", I don't know the answer to that. Mostly I don't know the use case for it
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.
Sorry for the confusion. Well in any case, I'll let your team discuss about it.
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 remember having written code exactly like that before and then being surprised that it didn't compile. I can't remember where that was and I must've found a different approach, but it seems like something that is consistent with how other parts of the language works. And it's kind of surprising/unexpected that it doesn't compile.
836bf7b
to
30a3e71
Compare
@@ -186,7 +186,11 @@ impl<'tcx> InherentCollect<'tcx> { | |||
return; | |||
}; | |||
|
|||
let self_ty = self.tcx.type_of(item.owner_id); | |||
let mut self_ty = self.tcx.type_of(item.owner_id); | |||
if matches!(self_ty.kind(), ty::Alias(..)) { |
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 guess this should either specifically check for projections or not have any check at all. The logic in rustc_privacy should be kept in sync with this
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.
If I remove the check, I have this panic:
error[E0391]: cycle detected when finding all inherent impls defined in crate
|
= note: ...which requires normalizing `I8<{i8::MIN}>`...
note: ...which requires evaluating type-level constant...
--> fake-test-src-base/symbol-names/const-generics.rs:20:9
|
LL | impl I8<{i8::MIN}> {
| ^^^^^^^^^
Also, doesn't it make sense to normalize it for type aliases too?
And final question: you mean that if we keep this check, we should have the same in privacy where I added it (just to confirm so I can update accordingly).
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.
If I remove the check, I have this panic:
that's an error, and I think it can be avoided by using the try_normalize
variant, just like at the other normalization added in this PR. The check you are doing is useless if the projection resolves to a type that would have errored without your check (as normalization is recursive/deep)
Also, doesn't it make sense to normalize it for type aliases too?
there are no type aliases in the type system yet ;) that's your other PR
you mean that if we keep this check, we should have the same in privacy where I added it (just to confirm so I can update accordingly).
I just mean that they should work as similarly as possible, so if both use the try variant, that seems okay.
Could you assign this PR to me when it's otherwise ready? |
30a3e71
to
143b2d3
Compare
143b2d3
to
45185aa
Compare
So we discovered that the normalization bug also appeared on this code: pub trait Identity {
type Identity: ?Sized;
}
impl<T: ?Sized> Identity for T {
type Identity = Self;
}
pub struct I8<const F: i8>;
impl <I8<{i8::MIN}> as Identity>::Identity {
pub fn foo(&self) {}
} meaning that the |
We discovered a use case in gtk-rs.
https://gtk-rs.org/gtk-rs-core/git/docs/glib_macros/derive.Properties.html#example cc @sdroege |
…tions, r=oli-obk Add ui test for implementation on projection The error in full can be seen in rust-lang#107263 and is part of why the PR is blocked (it still requires the approval from the team for supporting it). r? `@oli-obk`
…tions, r=oli-obk Add ui test for implementation on projection The error in full can be seen in rust-lang#107263 and is part of why the PR is blocked (it still requires the approval from the team for supporting it). r? ``@oli-obk``
☔ The latest upstream changes (presumably #108015) made this pull request unmergeable. Please resolve the merge conflicts. |
going to talk about this in a types team deep dive rust-lang/types-team#91 |
Got this one from #103985 as well.
Issue (solved) with privacy check
However, a bug appeared from the privacy check as the CI will show: it has some false positive with "private type in public interface". Not sure why though. The backtrace for it is here:
cc @compiler-errors
r? @oli-obk