-
-
Notifications
You must be signed in to change notification settings - Fork 14.9k
[POC] create an MVP for using Destruct for custom dtors
#156090
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?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -38,33 +38,7 @@ fn resolve_instance_raw<'tcx>( | |
| } else if tcx.is_lang_item(def_id, LangItem::DropInPlace) { | ||
| let ty = args.type_at(0); | ||
|
|
||
| if ty.needs_drop(tcx, typing_env) { | ||
| debug!(" => nontrivial drop glue"); | ||
| match *ty.kind() { | ||
| ty::Coroutine(coroutine_def_id, ..) => { | ||
| // FIXME: sync drop of coroutine with async drop (generate both versions?) | ||
| // Currently just ignored | ||
| if tcx.optimized_mir(coroutine_def_id).coroutine_drop_async().is_some() { | ||
| ty::InstanceKind::DropGlue(def_id, None) | ||
| } else { | ||
| ty::InstanceKind::DropGlue(def_id, Some(ty)) | ||
| } | ||
| } | ||
| ty::Closure(..) | ||
| | ty::CoroutineClosure(..) | ||
| | ty::Tuple(..) | ||
| | ty::Adt(..) | ||
| | ty::Dynamic(..) | ||
| | ty::Array(..) | ||
| | ty::Slice(..) | ||
| | ty::UnsafeBinder(..) => ty::InstanceKind::DropGlue(def_id, Some(ty)), | ||
| // Drop shims can only be built from ADTs. | ||
| _ => return Ok(None), | ||
| } | ||
| } else { | ||
| debug!(" => trivial drop glue"); | ||
| ty::InstanceKind::DropGlue(def_id, None) | ||
| } | ||
|
Comment on lines
-41
to
-67
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. For perf reasons I expect we should keep some of this shortcutting. Also whatever's happening with async drop feels important, why is it ok to remove it?
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'll have a look soon, thanks for pointing this out
Member
Author
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Sure, but why is that ok and why is that useful? Doesn't this return the wrong instance kind in some cases now? |
||
| return ty::Instance::try_resolve_drop_in_place(tcx, typing_env, ty); | ||
| } else if tcx.is_lang_item(def_id, LangItem::AsyncDropInPlace) { | ||
| let ty = args.type_at(0); | ||
|
|
||
|
|
@@ -166,6 +140,20 @@ fn resolve_associated_item<'tcx>( | |
| if !eligible { | ||
| return Ok(None); | ||
| } | ||
| if tcx.is_lang_item(trait_ref.def_id, LangItem::Destruct) { | ||
| if !tcx.is_lang_item(trait_item_id, LangItem::DestructDropInPlace) { | ||
| bug!( | ||
| "unexpected associated item for built-in `{trait_ref}`: {}", | ||
| tcx.item_name(trait_item_id) | ||
| ); | ||
| } | ||
|
|
||
| debug!("Got user Destruct impl"); | ||
| return Ok(Some(Instance { | ||
| def: ty::InstanceKind::Item(leaf_def.item.def_id), | ||
| args: rcvr_args, | ||
| })); | ||
| } | ||
|
Comment on lines
+143
to
+156
Member
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why is this early return useful/necessary? Please add a comment explaning its purpose |
||
|
|
||
| let typing_env = typing_env.with_post_analysis_normalized(tcx); | ||
| let (infcx, param_env) = tcx.infer_ctxt().build_with_typing_env(typing_env); | ||
|
|
@@ -403,6 +391,46 @@ fn resolve_associated_item<'tcx>( | |
| } else { | ||
| bug!("unexpected associated associated item") | ||
| } | ||
| } else if tcx.is_lang_item(trait_ref.def_id, LangItem::Destruct) { | ||
| debug!( | ||
| "resolving Destruct for ImplSource::Builtin: {:?}, {:?}, {:?}", | ||
| typing_env, trait_item_id, rcvr_args | ||
| ); | ||
| if !tcx.is_lang_item(trait_item_id, LangItem::DestructDropInPlace) { | ||
| bug!( | ||
| "unexpected associated item for built-in `{trait_ref}`: {}", | ||
| tcx.item_name(trait_item_id) | ||
| ); | ||
| } | ||
|
|
||
| let self_ty = trait_ref.self_ty(); | ||
|
|
||
| let def = if self_ty.needs_drop(tcx, typing_env) { | ||
| match *self_ty.kind() { | ||
| ty::Coroutine(coroutine_def_id, ..) => { | ||
| if tcx.optimized_mir(coroutine_def_id).coroutine_drop_async().is_some() | ||
| { | ||
| ty::InstanceKind::DropGlue(trait_item_id, None) | ||
| } else { | ||
| ty::InstanceKind::DropGlue(trait_item_id, Some(self_ty)) | ||
| } | ||
| } | ||
| ty::Closure(..) | ||
| | ty::CoroutineClosure(..) | ||
| | ty::Tuple(..) | ||
| | ty::Adt(..) | ||
| | ty::Dynamic(..) | ||
| | ty::Array(..) | ||
| | ty::Slice(..) | ||
| | ty::UnsafeBinder(..) => { | ||
| ty::InstanceKind::DropGlue(trait_item_id, Some(self_ty)) | ||
| } | ||
| _ => return Ok(None), | ||
| } | ||
| } else { | ||
| ty::InstanceKind::DropGlue(trait_item_id, None) | ||
| }; | ||
| Some(ty::Instance { def, args: rcvr_args }) | ||
| } else { | ||
| Instance::try_resolve_item_for_coroutine(tcx, trait_item_id, trait_id, rcvr_args) | ||
| } | ||
|
|
||
Uh oh!
There was an error while loading. Please reload this page.
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.
To limit the amount of trait-related magic, I would rather do this:
and then have the intrinsic be the only thing that's auto-generated.
View changes since the review
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.
IMO there isn't much trait magic right now; the resolver simply checks if there are any user impls, and only assembles builtin ones if there aren't any. IMO this indirection would be rather confusing and also might clash with Specialization
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 have the opposite intuition: having a method that magically has a body generated for it is not something that exists in rust; only intrinsics do that. And I don't see why this would interact with specialization in any way. Moreover this has the benefit that if someone wants to they can call the auto-generated drop glue.
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 person can still invoke
Destruct::drop_in_placemanually, although it causes smth like a double drop issue.I'll work on this. If you're talking about having both a custom dtor and the default one, i see very little usecase for that. Maybe that's just my intuition, but i prefer some less indirection, as this approach makes it more obvious how drop is being called (its just a function call, rather than what Drop::drop did, which called ptr::drop_in_place)
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 mean if I want to override
Destruct::drop_in_placein a way that reuses the default thing, e.g. because you want to call it conditionally. I agree it's probably rare.I'm confused:
Drop::dropnever calledptr::drop_in_place.