You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I am currently developing a type system to reason about the non-emptiness of container types (e.g, List, Set etc). I have annotated parts of the typetools JDK with @mernst with qualifiers from our type system, e.g.,
With this change, I would expect the following code to fail type-checking:
importjava.util.List;
importjava.util.LinkedList;
importorg.checkerframework.checker.nonempty.qual.UnknownNonEmpty;
importorg.checkerframework.checker.nonempty.qual.NonEmpty;
classIssue6407 {
voidfoo() {
// items initially has the type @UnknownNonEmptyList<String> items = newLinkedList<>();
items.add("hello");
@NonEmptyList<String> bar = items; // OKitems.remove("hello");
@NonEmptyList<String> baz = items; // I expect an error here
}
}
Specifically, I would expect the assignment to baz after the call to items.remove("hello") to fail, since List.remove is a side-effecting operation (i.e., not @Pure) and the type of the receiver is no longer guaranteed to be @NonEmpty.
However, this code type-checks cleanly.
Steps to Reproduce
Please follow the following sequence of shell commands
# Clone my fork of the Checker Framework
git clone git@github.com:jyoo980/checker-framework.git
# Clone my fork of the typetools JDK
git clone git@github.com:jyoo980/jdk.git
# Checkout the relevant branches# Note, ensure that the `checker-framework` repo and the `jdk` repo are sibling directories
(cd checker-framework && git checkout --filter=blob:none yoo/nonempty-checker)
(cd jdk && git checkout --filter=blob:none yoo/nonempty-annos)
# Build the Checker Frameworkcd checker-framework
./gradlew assemble
# Run the Non-Empty Checker on the test case from: https://gist.github.com/jyoo980/3bf7917ade06d644776af942d7312b34
checker/bin/javac -processor nonempty Issue6407.java
Expected output: the Non-Empty Checker should raise an assignment error at the last line Actual output: the Non-Empty Checker type-checks Main.java cleanly
The text was updated successfully, but these errors were encountered:
@jyoo980 it may be helpful to create a repro case that does not involve the JDK. That would be easier to turn into a regression test, and also it would eliminate the possibility of this issue being specific to the JDK classes somehow.
@msridhar We're tracking this over in my fork: jyoo980#1. I'll re-open this if needed. It's not a bug, but we had to override a default setting for dataflow.
Issue
I am currently developing a type system to reason about the non-emptiness of container types (e.g,
List
,Set
etc). I have annotated parts of the typetools JDK with @mernst with qualifiers from our type system, e.g.,The partially annotated JDK is available here.
With this change, I would expect the following code to fail type-checking:
Specifically, I would expect the assignment to
baz
after the call toitems.remove("hello")
to fail, sinceList.remove
is a side-effecting operation (i.e., not@Pure
) and the type of the receiver is no longer guaranteed to be@NonEmpty
.However, this code type-checks cleanly.
Steps to Reproduce
Please follow the following sequence of shell commands
Expected output: the Non-Empty Checker should raise an assignment error at the last line
Actual output: the Non-Empty Checker type-checks
Main.java
cleanlyThe text was updated successfully, but these errors were encountered: