Skip to content
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

Creating synthetic classes for unsolved FieldAccessExpr #61

Merged
merged 5 commits into from
Dec 3, 2023

Conversation

LoiNguyenCS
Copy link
Collaborator

No description provided.

@LoiNguyenCS
Copy link
Collaborator Author

Professor,

This PR adds the codes and tests for unsolved FieldAccessExpr instances. The updateClassSetWithQualifiedFieldSignature method in this PR mainly relies on the existing updateClassSetWithQualifiedStaticMethodCall method.

Please take a look. Thank you.

@LoiNguyenCS LoiNguyenCS requested a review from kelloggm December 1, 2023 22:12
// this check is not very comprehensive, since a class can be in lowercase, and a method or
// field can be in uppercase. But since this is without the jar paths, this is the best we can
// do.
return Character.isUpperCase(field.getScope().toString().charAt(0));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't fully understand why being uppercase tells us whether the field is unsolved. Is there some other invariant here that I'm missing, such as that unsolved fields always are static and need to be accessed via a class name?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Professor, I will rename it. We know the field is unsolved because in the visit method for FieldAccessExpr, we check to see if the field is solved first before coming to this check.

Copy link
Collaborator Author

@LoiNguyenCS LoiNguyenCS Dec 2, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please neglect my earlier response. Before that line, we have a try-catch block to see if the field is solvable. The uppercase check is for the caller of this field. Since we don't have jar paths, we simply assume that if a symbol is capital, then that capital is a class name.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still not fully happy with this, but I'll let it go for now as tech debt given the need to move quickly

@LoiNguyenCS
Copy link
Collaborator Author

Professor,

I have updated the codes based on your suggestions. Please take a look. Thank you.

@LoiNguyenCS LoiNguyenCS requested a review from kelloggm December 2, 2023 18:19
// this check is not very comprehensive, since a class can be in lowercase, and a method or
// field can be in uppercase. But since this is without the jar paths, this is the best we can
// do.
return Character.isUpperCase(field.getScope().toString().charAt(0));
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm still not fully happy with this, but I'll let it go for now as tech debt given the need to move quickly

@kelloggm kelloggm merged commit 7e27bf2 into njit-jerse:main Dec 3, 2023
1 check passed
@kelloggm kelloggm deleted the unsolved-field-access branch December 3, 2023 22:13
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants