-
-
Notifications
You must be signed in to change notification settings - Fork 14.5k
Remove 'static requirement on try_as_dyn #150161
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
base: main
Are you sure you want to change the base?
Conversation
|
r? @SparrowLii rustbot has assigned @SparrowLii. Use |
This comment has been minimized.
This comment has been minimized.
e7ef1ee to
29f1dba
Compare
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.
Some drive-by comments; but I'm not rustc/HIR-savy, so take these with a grain of salt 🙇
tests/ui/any/non_static.rs
Outdated
| assert!(std::any::try_as_dyn::<_, dyn Trait>(&()).is_some()); | ||
| assert!(std::any::try_as_dyn::<_, dyn Trait>(&&[()]).is_some()); | ||
| assert!(std::any::try_as_dyn::<_, dyn Trait>(&&()).is_some()); | ||
| assert!(std::any::try_as_dyn::<_, dyn Trait>(&&42_u32).is_none()); |
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 one is a "regression", right? With the old design we could be involving a &'static u32 which is both : 'static, and implementing Trait in the classical sense. Perhaps we'll want a try_as_dyn_static() function as well, for those interested in this use case?
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'll add this to the tracking issue
| if let TypingMode::Reflection = ecx.typing_mode() | ||
| && !cx.is_fully_generic_for_reflection(impl_def_id) | ||
| { | ||
| return Err(NoSolution); |
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 is way over my head, lol, but just to sanity-check: could this branch be hoisted to the beginning of the function, as in, any impl that is not fully_generic_for_reflection(), when checking in Reflection mode, ought to result in Err(NoSolution), right? As in, it's not specific to this double-Negative branch?
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.
Well, it's only relevant if the polarities match. Otherwise it's not a match anyway. So while it could be lifted to the front, it's not really necessary either. No strong opinion, but also easily changeable without affecting behavior
|
r? BoxyUwU |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
29f1dba to
fe33b0c
Compare
This comment has been minimized.
This comment has been minimized.
dfa5c33 to
30f5641
Compare
|
|
||
| fn extend(a: &Payload) -> &'static Payload { | ||
| // TODO: should panic at the `unwrap` here | ||
| let b: &(dyn Trait + 'static) = try_as_dyn::<&Payload, dyn Trait + 'static>(&a).unwrap(); |
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 don't have a solution for this yet. The easy hammer is to reject traits that have such methods. Nicer would be to figure out how to make a bound that ensures the dyn Trait's lifetimes are shorter than the arguments'
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.
Can we check during mir_typeck that the source type outlives the lifetime of the trait object type?
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.
ah its not the intrinsic 🤔 yeah thats tricky
This comment has been minimized.
This comment has been minimized.
|
The hacky solution is obviously not a general fix. But I think it's progress. As a next step I will add the input type as a generic parameter on |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
c027131 to
96dfdf7
Compare
|
This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
|
Do we need to prohibit manually implementing |
|
Yea I think it's pretty useless to impl, feels similar to the |
fun... if the input type also is behind a binder, I can't really construct the obligation |
|
@oli-obk Why does the input type |
|
Well. What I'm trying to emulate here is a version of the logic that coercion does when going from T to dyn Trait. But since we need to do it for all T here, we can't just look at the right impl and perform the appropriate obligation checks. Instead we need to have the most pessimistic view on how any type can implement that trait. So, generic lifetimes of the trait must always be outlived by the self type. Since you can shuttle lifetimes through generic type params, generic type params of the trait must only contain lifetimes that are outlived by the self type, too. But since we do not have such constraints anywhere else in the language, I'm just gonna make the presence of generic type params on the trait cause a |
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
96dfdf7 to
6c42a6c
Compare
This comment has been minimized.
This comment has been minimized.
35cbc7c to
914b5e2
Compare
This comment has been minimized.
This comment has been minimized.
|
I had a look at this one last time. I think it should be good to go in terms of soundness. |
914b5e2 to
bf73dc3
Compare
|
The job Click to see the possible cause of the failure (guessed by this bot) |
|
☔ The latest upstream changes (presumably #152437) made this pull request unmergeable. Please resolve the merge conflicts. |
tracking issue: #144361
cc @theemathas can you find an unsoundness when combined with generic impls where there are no lifetimes, but reference other impls that have lifetimes with constraints? I couldn't find anything.
cc @ivarflakstad @izagawd