typetools / typetools/checker-framework
False-Positive involving overridden and overlapping interfaces (and specific interface names)
@smillst is already working on this.
Since Mar 3, 2022.
- Dominant language
- Java
- Stars
- 1.1k
- Forks
- 440
- Avg merge
- 1d 12h
- Merged PRs (30d)
- 134
Description
I am using the Gradle plugin (v 0.6.8) to invoke the CheckerFramework (v 3.21.2).
I briefly tried to come up with a more minimal example, but it appears that the condition under which this issue can be reproduced is quite fragile. Even changes to the interface names (maybe affecting their alphabetical ordering) have an effect on whether the issue can be reproduced.
Reproduction example:
public interface HasMaybeName {
public @Nullable String getName();
}
public interface HasName extends HasMaybeName {
@Override
public @NonNull String getName();
}
// If I rename this to 'ExtendedHasMaybeName' instead of 'OExtendedHasMaybeName'
// I cannot reproduce the issue anymore.
public interface OExtendedHasMaybeName extends HasMaybeName {
@Override
public @Nullable String getName();
}
public interface Thing extends HasName, OExtendedHasMaybeName {
}
public class ActualThing implements Thing {
@Override
public @NonNull String getName() {
return "";
}
}
public class Test {
public static Thing getThing() {
return new ActualThing();
}
public static void foo() {
Thing thing = getThing();
@NonNull String name = thing.getName(); // Error
doSth(name);
doSth(thing.getName()); // Error
}
public static void doSth(String name) {
assert System.out != null;
System.out.println(name);
}
}
CF reports the following errors:
[assignment] incompatible types in assignment.
@NonNull String name = thing.getName(); // Error
^
found : @Initialized @Nullable String
required: @UnknownInitialization @NonNull String
[argument] incompatible argument for parameter name of doSth.
doSth(thing.getName()); // Error
^
found : @Initialized @Nullable String
required: @Initialized @NonNull String
I would expect CF to consider the return type of the hasName method to be non-null, since at least one of the implemented/extended interfaces of Thing contains the method with this signature with a non-null return type.
Depending on how I name the interfaces in my reproduction example, CF even correctly considers the return type as non-null.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.