-
Notifications
You must be signed in to change notification settings - Fork 14.9k
[NFCI][analyzer] Make CallEvent::getState protected #162673
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 1 commit
769a309
e0d10ba
ca65416
1d76d59
dd4a5c7
847bb88
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 |
|---|---|---|
|
|
@@ -211,6 +211,16 @@ class CallEvent { | |
| getExtraInvalidatedValues(ValueList &Values, | ||
| RegionAndSymbolInvalidationTraits *ETraits) const {} | ||
|
|
||
| /// The state in which the call is being evaluated. | ||
| /// CallEvent instances have a reference to a state object instead of storing | ||
| /// the argument `SVal`s, the return value (if available), the dynamic type | ||
| /// information and similar things as separate data members. However, the | ||
| /// existence of this state object is an implementation detail (and perhaps | ||
| /// it should be eventually eliminated), so use of this method should be | ||
| /// avoided if possible. (The checker callbacks can and should access the | ||
| /// canonical state through the CheckerContext.) | ||
| const ProgramStateRef &getState() const { return State; } | ||
|
|
||
| public: | ||
| CallEvent &operator=(const CallEvent &) = delete; | ||
| virtual ~CallEvent() = default; | ||
|
|
@@ -231,8 +241,14 @@ class CallEvent { | |
| } | ||
| void setForeign(bool B) const { Foreign = B; } | ||
|
|
||
| /// The state in which the call is being evaluated. | ||
| const ProgramStateRef &getState() const { return State; } | ||
| /// Returns the ASTContext which is (indirectly) associated with this call | ||
| /// event. This method is exposed for the convenience of a few checkers that | ||
| /// need the AST context in functions that take a CallEvent as argument. For | ||
| /// the sake of clarity prefer to get the ASTContext from more "natural" | ||
| /// sources (e.g. the CheckerContext) instead of using this method! | ||
|
||
| ASTContext &getASTContext() const { | ||
steakhal marked this conversation as resolved.
Outdated
Show resolved
Hide resolved
|
||
| return getState()->getStateManager().getContext(); | ||
| } | ||
|
|
||
| /// The context in which the call is being evaluated. | ||
| const LocationContext *getLocationContext() const { return LCtx; } | ||
|
|
||
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.
By reading the comment it was not clear to me why it returns a state by const ref.
State objects can never be mutated. Only a new one could be constructed that applies the mutation one desired.
BTW I also feel like a comment should fit into a single line, or maybe just a couple of lines, if the intention is that someone should read it.
If the message can't be expressed in that limited space, it must be chunked, to make it easier to read. Possibly also use Doxygen note or similar sections.
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 just moved this method from the
publicsection toprotectedwithout modifying its signature. You're right that there is no reason to take the state by (const) ref, so I'll update it.I'll try to reduce the length of the comment -- although personally I read and often prefer long and explicit comments.
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.
I see. So the discouragement is to avoid more dependence on using the State. IMO. if that is a concern, we could easily swap that State for a reference to the ASTContext if we decide to drop that State field.
To me, the comment does not pull its weight, and probably confusing (just like it did confuse me).
Probably any comments about the State filed should go to the field declaration, and not to this getter.
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.
Is this still relevant after my commit e0d10ba or did I manage to clarify it?
You are right that "we could easily swap that State for a reference to the ASTContext if we decide to drop that State field" and therefore we don't strictly need the discouragement before
getASTContext()[which is btw the other big comment block] -- but I still feel that "can provide anASTContext" is not a "natural" responsibility for a call event object, so I would prefer to keep this discouragement.The warning which highlights the use of the state object belongs to the getter, because a developer who wants to use
getState()perhaps looks at its declaration and sees the warning, but almost surely won't look at the field declaration. (Although perhaps we should renamegetStatetogetStateUnsafeto highlight that there is something fishy going on, because otherwise developers happily autocompletegetStatewithout seeing the warning comment.)You're right that the TODO note for replacing the State field with smaller individual fields would logically belong to the field declaration, but it is also closely related to the warning comment, so I don't want to separate it from there.