-
Notifications
You must be signed in to change notification settings - Fork 10.5k
Add the drop_deinit
instruction
#65060
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
Conversation
his instruction is a marker for a following destroy instruction to suppress the call of the move-only type's deinitializer.
…gument This happens for address-only move-only types.
…eeded by a drop_deinit rdar://105798769
@swift-ci test |
I am fine 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.
Thanks @eeckstein. Looks great!
%1 = drop_deinit %0 : $T | ||
// T must be a move-only type | ||
// %1 is an @owned T | ||
%3 = drop_deinit %2 : $*T |
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.
@eeckstein do we need to support an address form for drop_deinit
?
I really hope we don't need that! It's easy to misuse and hard to verify.
In the meantime, can you remove it from the docs?
If we need an address form, we should discuss whether that should be drop_deinit_addr
. Generally, instructions should have fixed number and type of operands except in special cases. debug_value
is an exception where it works out ok. But an instruction that produces a new address is not straightforward.
The
drop_deinit
instruction is a marker for a following destroy instruction to suppress the call of the move-only type's deinitializer.SILGen needs to insert
drop_deinit
in move-only deinitializers to avoid that - due to other optimizations, like inlining - the deinitializer call is inserted multiple times.rdar://105798769