- Notifications
You must be signed in to change notification settings - Fork 15.3k
[clang][TSA] Make RequiresCapability a DeclOrType attribute #67095
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 |
|---|---|---|
| | @@ -212,6 +212,19 @@ int main(void) { | |
| mutex_exclusive_unlock(late_parsing.a_mutex_defined_very_late); | ||
| mutex_exclusive_unlock(late_parsing.a_mutex_defined_late); | ||
| #endif | ||
| /// Function pointers | ||
| { | ||
| int __attribute__((requires_capability(&mu1))) (*function_ptr)(int) = Foo_fun1; | ||
AaronBallman marked this conversation as resolved. Outdated Show resolved Hide resolved | ||
| | ||
| function_ptr(5); // expected-warning {{calling function 'function_ptr' requires holding mutex 'mu1'}} | ||
| | ||
| mutex_exclusive_lock(&mu1); | ||
| int five = function_ptr(5); | ||
| mutex_exclusive_unlock(&mu1); | ||
| | ||
| int (*function_ptr2)(int) = function_ptr; | ||
| function_ptr2(5); | ||
| } | ||
| | ||
| ||
| return 0; | ||
| } | ||
| | ||
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.
Okay, maybe we do want to do this change separately. I think I was wrong about modeling after this; I think we want it to be done like
handleFunctionTypeAttr()andFUNCTION_TYPE_ATTRS_CASELISTso that it becomes part of theFunctionTypeitself. That's what would get us the diagnostics on type mismatches (we look throughAttributedTypeas sugar:llvm-project/clang/include/clang/AST/Type.h
Line 4999 in 28b7e28
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.
Hmmmm, my intuition is that if we don't do this work now, we'll forever be stuck with the current behavior where we don't diagnose pointer mismatches because someone will rely on that continuing to work. So maybe we do want to do this work now...
CC @erichkeane @aaronpuchert for opinions on whether we think this needs to diagnose mismatches in the initial offering of it as a type attribute.
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 I agree Aaron, if we don't diagnose now, it'll be pretty ugly to do it later.
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.
Meh, it seems like adding a pointer to
FunctionType::ExtInfowould blow it up a lot, and just a bit isn't enough to save the information.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.
There were a few changes there recently... i wonder if it is time to just accept that we're going all-in on trailing-storage for this type. We're now doing it for the ARM SVE types, plus the 'lesser used' structure, so perhaps the 'capability pointer' can end up there too. WDYT?
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.
@AaronBallman Does this sound like the way to go to you as well?
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.
No, we don't want to modify
FunctionType::ExtInfo, I think what @erichkeane was talking about is that we added trailing objects toFunctionProtoTypethat we can squirrel lesser-used data into. That might be reasonable here because I cannot imagine anyone using thread safety attributes with K&R C interfaces, but that would be the downside to putting the data onFunctionProtoType.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.
It would kind of stink to have to do it in 2 places, but it could go in trailing-storage/etc on
FunctionProtoTypeandFunctionNoProtoType, then just disambiguate it with a function. So it doesn't need to end up inFunctionType::ExtInfoorFunctionTypeitself.