-
Notifications
You must be signed in to change notification settings - Fork 19
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
Remove non-static fields from the initial store of a static method #216
Conversation
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, just a small suggestion.
Separately, can you look whether store.insertValue
can ever be called twice for the same field, first with the initializer and then with the declared type? The conditions don't seem to exclude this.
Should the first if
also include varEle.getEnclosingElement().equals(classEle)
? It would be more readable if that condition is extracted into another boolean with a more descriptive name.
framework/src/main/java/org/checkerframework/framework/flow/CFAbstractTransfer.java
Outdated
Show resolved
Hide resolved
For the first one, yes, the For the second question, yes, I think so. But in what circumstance will the |
Re 1: Can you test what happens? I would assume the second insert overwrites the value from the first, making this rather pointless. Re 2: Remove the check and see whether a test case fails. It might be related to nested classes and that the returned set of fields also contains fields from nested or enclosing classes that shouldn't be there. (Although, why shouldn't the store contain a field from an enclosing class? So maybe just nested classes should be excluded.) |
Now I understand! the second insert with value |
After removing Is this because, this version inserts the field from enclosing class in store as |
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!
TypeElement classEle = TreeUtils.elementFromDeclaration(classTree); | ||
for (FieldInitialValue<V> fieldInitialValue : analysis.getFieldInitialValues()) { | ||
VariableElement varEle = fieldInitialValue.fieldDecl.getField(); | ||
boolean fieldNotFromEnclosingClass = varEle.getEnclosingElement().equals(classEle); |
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.
Should the Not
be removed from the variable name?
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.
If varEle.getEnclosingElement().equals(classEle)
is true, varEle
is in classEle
, then this field is not from enclosing class right?
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'm not sure where the confusion is here. The enclosing element of varEle
is some class. If that class is equal to classEle
, then the field is directly within classEle
.
What element do you mean with "the enclosing class"?
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.
Meaning classEle
is the nested class. The "enclosing class", encloses classEle
. So if the field is directly within classEle
, it's not from the enclosing class.
Yeah, the naming is a bit ambiguous. How about fieldNotFromOuterClass
?
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's usually easier to avoid negations. How about isFieldOfCurrentClass
?
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.
Yes, I agree!
framework/src/main/java/org/checkerframework/framework/flow/CFAbstractTransfer.java
Outdated
Show resolved
Hide resolved
framework/src/main/java/org/checkerframework/framework/flow/CFAbstractTransfer.java
Outdated
Show resolved
Hide resolved
framework/src/main/java/org/checkerframework/framework/flow/CFAbstractTransfer.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Werner Dietl <wdietl@gmail.com> Co-authored-by: zcai <z44cai@uwaterloo.ca>
TypeElement classEle = TreeUtils.elementFromDeclaration(classTree); | ||
for (FieldInitialValue<V> fieldInitialValue : analysis.getFieldInitialValues()) { | ||
VariableElement varEle = fieldInitialValue.fieldDecl.getField(); | ||
boolean fieldNotFromEnclosingClass = varEle.getEnclosingElement().equals(classEle); |
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's usually easier to avoid negations. How about isFieldOfCurrentClass
?
framework/src/main/java/org/checkerframework/framework/flow/CFAbstractTransfer.java
Outdated
Show resolved
Hide resolved
framework/src/main/java/org/checkerframework/framework/flow/CFAbstractTransfer.java
Outdated
Show resolved
Hide resolved
Co-authored-by: Werner Dietl <wdietl@gmail.com>
I think this pull request is nearly done. During the discussion, we found one false negative, and I opened a new issue for 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 for the improvements and cleanups!
This PR is to fix issue #215
Below is the CFG graph produced by this branch.

As we can see, this.f has been removed from the initial store.