-
Notifications
You must be signed in to change notification settings - Fork 15.2k
[Clang][NFC] Refactor operator delete argument handling #160554
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
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 |
|---|---|---|
|
|
@@ -3552,6 +3552,53 @@ void FunctionDecl::setIsTypeAwareOperatorNewOrDelete(bool IsTypeAware) { | |
| getASTContext().setIsTypeAwareOperatorNewOrDelete(this, IsTypeAware); | ||
| } | ||
|
|
||
| UsualDeleteParams FunctionDecl::getUsualDeleteParams() const { | ||
| UsualDeleteParams Params; | ||
|
|
||
| // This function should only be called for operator delete declarations. | ||
| assert(getDeclName().isAnyOperatorDelete()); | ||
| if (!getDeclName().isAnyOperatorDelete()) | ||
| return Params; | ||
|
|
||
| const FunctionProtoType *FPT = getType()->castAs<FunctionProtoType>(); | ||
| auto AI = FPT->param_type_begin(), AE = FPT->param_type_end(); | ||
|
Collaborator
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. What does
Collaborator
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. Thats pre-existing (though different capitalization, but I'll guess it is supposed to be 'args-iterator' and 'args-end'. But thats a guess, and also kinda wrong, since these are parameters not args.
Collaborator
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 you can squint and say it is existing code but if no one understand what the variable names mean, it probably makes sense to just rename them. Your idea seems plausible. |
||
|
|
||
| if (isTypeAwareOperatorNewOrDelete()) { | ||
| Params.TypeAwareDelete = TypeAwareAllocationMode::Yes; | ||
| assert(AI != AE); | ||
| ++AI; | ||
| } | ||
|
|
||
| // The first argument after the type-identity parameter (if any) is | ||
| // always a void* (or C* for a destroying operator delete for class | ||
| // type C). | ||
| ++AI; | ||
|
|
||
| // The next parameter may be a std::destroying_delete_t. | ||
| if (isDestroyingOperatorDelete()) { | ||
| assert(!isTypeAwareAllocation(Params.TypeAwareDelete)); | ||
| Params.DestroyingDelete = true; | ||
| assert(AI != AE); | ||
| ++AI; | ||
| } | ||
|
|
||
| // Figure out what other parameters we should be implicitly passing. | ||
| if (AI != AE && (*AI)->isIntegerType()) { | ||
| Params.Size = true; | ||
| ++AI; | ||
| } else | ||
| assert(!isTypeAwareAllocation(Params.TypeAwareDelete)); | ||
|
|
||
| if (AI != AE && (*AI)->isAlignValT()) { | ||
| Params.Alignment = AlignedAllocationMode::Yes; | ||
| ++AI; | ||
| } else | ||
| assert(!isTypeAwareAllocation(Params.TypeAwareDelete)); | ||
|
|
||
| assert(AI == AE && "unexpected usual deallocation function parameter"); | ||
| return Params; | ||
| } | ||
|
|
||
| LanguageLinkage FunctionDecl::getLanguageLinkage() const { | ||
| return getDeclLanguageLinkage(*this); | ||
| } | ||
|
|
||
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.
@erichkeane is it reasonable to have this here but the struct definition be in a separate header? Moving the definition to Decl.h, requires a bunch of other related definitions to be moved - I think it would be reasonable to do so if we're going to make this present directly in Decl?
@andykaylor I think this should be an optional return - e.g.
std::optional<UsualDeleteParams>or we could smooth out the declaration w/o the definition withbool getUsualDeleteParams(UsualDeleteParams *) const. I'd preferoptional<UsualDeleteParams>given the alternation oftrueandfalsemeaning success or fail in different places.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 concern with it. Though, you can't really call the function at all without also including ExprCXX.h of course (since it returns a type requiring completeness).
We do this a few other places of course.
The
std::optionalmight be nice, but what state is it supposed to represent? Are you just meaning "for a non-delete decl"? At that point, an assert is probably even better.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.
So rather than assert and return the default structure if it's called for a non-delete function it would just return
std::nullopt?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 that's my preference? Though I realize I was thinking we could remove the individual queries but that would require the addition of an equivalent struct for new - but that might be nicer in general? There are existing structs that are similar and maybe we could make things generally nicer by reducing the number of variations of these structures?
Such a change would not be necessary as part of this PR of course - on the other hand maybe an assertion is perfectly reasonable? That is consistent with lots of other code.
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.
@andykaylor actually yeah, lets stick with an assertion for now - changing the structure of new/delete queries is a different task from this one. r=me.