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.

Sign up for GitHub

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

Jump to bottom

Support unique classes (Fixes #3313) #3336

Merged
merged 35 commits into from
Jul 21, 2020
Merged

Support unique classes (Fixes #3313) #3336

Show file tree
Hide file tree
Changes from 10 commits
Commits
Show all changes
35 commits
Select commit Hold shift + click to select a range
fd536c4
Fix for feature request #3313 in Aliasing Checker
aditya3434 May 26, 2020
126014d
Fix for explicit annotation check in Aliasing Checker
aditya3434 May 28, 2020
b2b91eb
Adding test cases for removal of explicit annotation check
aditya3434 May 28, 2020
1b756c0
Ensuring all framework tests are passed
aditya3434 May 29, 2020
4edfc68
Formatting changes
aditya3434 May 29, 2020
dde03ef
Merge ../checker-framework-branch-master into 3313-explicit-annotatio…
mernst Jun 3, 2020
22462e0
Fix for feature request #3313 in Aliasing Checker
aditya3434 May 26, 2020
017082b
Revert "Fix for feature request #3313 in Aliasing Checker"
aditya3434 May 28, 2020
4b36609
Merge branch 'master' into 3313-explicit-annotation-fix
aditya3434 Jun 6, 2020
fa03246
Merge branch '3313-explicit-annotation-fix' of https://github.com/adi…
aditya3434 Jun 6, 2020
97ff12d
Fix for feature request #3313 in Aliasing Checker
aditya3434 May 26, 2020
629a1a9
Revert "Fix for feature request #3313 in Aliasing Checker"
aditya3434 May 28, 2020
25b602a
Merge remote-tracking branch 'upstream/master'
aditya3434 Jun 16, 2020
91d8372
Merge branch 'master' into 3313-explicit-annotation-fix
aditya3434 Jun 16, 2020
eb424fd
Fix for feature request #3313 in Aliasing Checker
aditya3434 May 26, 2020
c324094
Revert "Fix for feature request #3313 in Aliasing Checker"
aditya3434 May 28, 2020
941cab0
Fix for feature request #3313 in Aliasing Checker
aditya3434 May 26, 2020
d71f608
Revert "Fix for feature request #3313 in Aliasing Checker"
aditya3434 May 28, 2020
53a6c12
Merge remote-tracking branch 'upstream/master'
aditya3434 Jun 19, 2020
ff1b9e4
Merge branch 'master' into 3313-explicit-annotation-fix
aditya3434 Jun 19, 2020
135b266
Resolving review comments
aditya3434 Jun 19, 2020
db149b9
Removing redundant variables
aditya3434 Jun 19, 2020
e64f002
Modifying documentation
aditya3434 Jun 19, 2020
167d9cc
Merge branch 'master' into 3313-explicit-annotation-fix
aditya3434 Jun 27, 2020
cf45fd6
Making requested changes
aditya3434 Jun 27, 2020
f3d2479
Modifying documentation
aditya3434 Jun 27, 2020
9b60d82
Deleting stubfile.astub
aditya3434 Jun 28, 2020
1335ba2
Removing stubfile.astub references
aditya3434 Jun 28, 2020
1da4103
Merge branch 'master' into 3313-explicit-annotation-fix
aditya3434 Jul 11, 2020
7b191e9
Merge branch 'master' into 3313-explicit-annotation-fix
aditya3434 Jul 13, 2020
bd1fe05
Merge branch 'master' into 3313-explicit-annotation-fix
aditya3434 Jul 15, 2020
37976e8
Merge branch 'master' into 3313-explicit-annotation-fix
aditya3434 Jul 17, 2020
1523897
Merge branch 'master' into 3313-explicit-annotation-fix
aditya3434 Jul 18, 2020
79f35f1
Merge branch 'master' into 3313-explicit-annotation-fix
aditya3434 Jul 21, 2020
f6e67cc
Making requested changes
aditya3434 Jul 21, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
8 changes: 7 additions & 1 deletion framework/src/main/java/org/checkerframework/common/aliasing/AliasingVisitor.java
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -271,7 +271,13 @@ private boolean canBeLeaked(Tree exp) {
AnnotatedTypeMirror type = atypeFactory.getAnnotatedType(exp);
Copy link
Member

Choose a reason for hiding this comment

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

You should also update the javadoc with the change in behavior.
Do you understand what canBeLeaked expresses? The documentation is rather unclear.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have changed the documentation for the canBeLeaked method in my latest commit

boolean isMethodInvocation = exp.getKind() == Kind.METHOD_INVOCATION;
boolean isNewClass = exp.getKind() == Kind.NEW_CLASS;
return type.hasExplicitAnnotation(Unique.class) && !isMethodInvocation && !isNewClass;
boolean isArray = type.getUnderlyingType().getKind().toString().equalsIgnoreCase("array");
Copy link
Member

Choose a reason for hiding this comment

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

You should try to avoid operations on strings. Is there no TypeKind to compare against?

Copy link
Member

Choose a reason for hiding this comment

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

Ping.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have used your suggested logic in my latest commit. There is no need for array TypeKind comparison in the code.

boolean isNull = exp.getKind() == Kind.NULL_LITERAL;
if (type.getUnderlyingType().toString().startsWith("java.lang") || isArray || isNull) {
Copy link
Member

Choose a reason for hiding this comment

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

What is the motivation for this special logic? You should explain the logic here or at least in the PR description.

Copy link
Member

Choose a reason for hiding this comment

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

Also, do add tests that cover such special logic, in at least a few important cases.

Copy link
Contributor Author

@aditya3434 aditya3434 Jun 6, 2020 •
edited

Choose a reason for hiding this comment

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

The main logic I was following that the Aliasing Checker doesn't check for explicit annotations for user defined classes. So only those classes that the user has specifically annotated as @unique would construct @unique classes. This would also prevent all trivial objects like strings, int, object, float, etc. from always becoming @unique (it is more convenient to explicitly annotate them).

However, I couldn't figure out how to make the AliasingVisitor check whether a class was user-defined or not. So, instead I listed classes and data types for which one would need explicit annotations. These included java.lang classes, arrays and null values. All this complicated conditions could be avoided if the Visitor could check for user-defined classes.

if (annotated class is user defined) {
return type.hasAnnotation(Unique.class) && !isMethodInvocation && !isNewClass;
}
else {
return type.hasExplicitAnnotation(Unique.class) && !isMethodInvocation && !isNewClass;
}

Copy link
Member

Choose a reason for hiding this comment

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

Can you clarify what you mean with "user defined"?
Why should the handling of explicit annotations depend on whether the class is "user defined"?

Copy link
Contributor Author

@aditya3434 aditya3434 Jun 8, 2020 •
edited

Choose a reason for hiding this comment

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

In the stub file stubfile.astub in tests/aliasing, Object and String classes are annotated as @unique by default. So, if I don't check for explicit annotations for all classes, then, even trivial operations like string assignments give a "unique.leaked" error in the test cases.

// part of TypeRefinementTest.java in tests/aliasing
void rule1() {
String unique = new String();
isUnique(unique);
String notUnique = unique; // gives unique.leaked error even though @unique is never used
}

So I decided to limit this checking for "user-defined" classes (classes that are not part of any in-built java library, like java.lang or java.util). For example, in the code in the feature request #3313 (#3313), class Data and Demo are user-defined classes, and since Data is annotated as @unique, all its instances don't require explicit annotations to be unique as well.

Copy link
Member

Choose a reason for hiding this comment

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

We do not want different behavior for built-in classes and user-defined classes. The same logic should be applied to all source code, regardless of who wrote the code.

There is a difference between classes String and Data in these two examples.
In String the default constructor is annotated as returning a unique object. The class declaration is not annotated. Therefore, it is fine in the test case to have a non-unique String reference.
On the other hand class Data in this new test case is annotated as @Unique requiring that only @Unique references exist.
So your check should be for that difference between the two classes.

Also can you move the annotations from framework/tests/aliasing/stubfile.astub into typetools/jdk#52?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I have added a new method for the above requested logic. Now the code doesn't need to deal with the special cases of arrays, null and java.lang classes. I have used the getDeclAnnotations method to get the set of declared annotations of the class as a whole, and then searched for the unique annotation mirror in the set. The code now gives leaked errors without explicit annotations only when the class is annotated as @unique. Annotating just the constructor will allow non-unique object references.

return type.hasExplicitAnnotation(Unique.class) && !isMethodInvocation && !isNewClass;
} else {
return type.hasAnnotation(Unique.class) && !isMethodInvocation && !isNewClass;
}
}

private boolean isInUniqueConstructor() {
Expand Down
13 changes: 13 additions & 0 deletions framework/tests/aliasing/ExplicitAnnotationTest.java
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -0,0 +1,13 @@
import org.checkerframework.common.aliasing.qual.Unique;

@Unique class Data {
@SuppressWarnings("unique.leaked")
Data() {} // All objects of Data are now @Unique
}

class Demo {
void check(Data p) { // p is @Unique Data Object
// :: error: (unique.leaked)
Data y = p; // @Unique p is leaked
Copy link
Member

Choose a reason for hiding this comment

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

Is the type of the left-hand side important? Can you add another method that does

Object check2(Data p) { return p; }

which I guess should also give a unique.leaked error.

Copy link
Member

Choose a reason for hiding this comment

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

Ping.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

No, the type of the left-hand side isn't important. However, the method doesn't give an error, even when Data is explicitly annotated as @unique.

Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure how you mean this. Does Object z = p; not raise an error? Shouldn't it?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@Unique
class Data {

    Object check2(Data p) { return p; }

    void check(Data p) {
        Object z = p;
    }
}

In the code given above, Object z = p; does raise an error. Hence, the left hand side isn't important. However, the check2 function (where you are returning a @unique Data as an Object) doesn't raise an error both in the typetools/master and in my modified code, even if the Data p is explicitly annotated as @unique Data p.

Copy link
Member

Choose a reason for hiding this comment

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

Ok, can you expand this test case with the Object local variable and the expected error.
Then file an issue that shows the problem with the return version.

}
}