Add lost qualifier to viewpointtest type checker #827
Conversation
TODO: lost is not reflexive |
framework/src/test/java/viewpointtest/ViewpointTestQualifierHierarchy.java
Outdated
Show resolved
Hide resolved
| @@ -17,6 +17,7 @@ void foo() { | |||
| void invokeConstructor(@A Object aObj, @B Object bObj, @Top Object topObj) { | |||
| @A Object a = new @A VarargsConstructor(aObj); | |||
| @B Object b = new @B VarargsConstructor(bObj); | |||
| // :: error: (argument.type.incompatible) | |||
| @Top Object top = new @Top VarargsConstructor(topObj); | |||
There was a problem hiding this comment.
I think this is a tricky one.
For other uses of Top, we want Lost as the result, because the actual receiver could be some subtype of Top.
E.g. in ref.m(x) if ref has static type Top, it could still point to an A object and we need to use Lost to avoid a confusion.
For constructor invocations, that argument doesn't hold - we always instantiate the object with the most concrete type - there is an actual Top object and invoking it with Top is okay.
This is different from PICO and Universes, where one can never have an object with concrete type Readonly.
I don't know what to do with this now... Maybe forbid creating Top objects? Or document that handling of Top is a bit inconsistent?
There was a problem hiding this comment.
Forbid creating Top objects sounds good to me. Does it apply all systems that use viewpoint adapation?
There was a problem hiding this comment.
Not to all VP systems. But if VP with some qualifier results in Lost, that qualifier probably can't be created - Lost comes from not knowing some relationship. If one can create an object of that type, one knows the relationship.
So in this system, forbidding Top makes sense.
Co-authored-by: Werner Dietl <[email protected]>
| @@ -17,6 +17,7 @@ void foo() { | |||
| void invokeConstructor(@A Object aObj, @B Object bObj, @Top Object topObj) { | |||
| @A Object a = new @A VarargsConstructor(aObj); | |||
| @B Object b = new @B VarargsConstructor(bObj); | |||
| // :: error: (argument.type.incompatible) | |||
| @Top Object top = new @Top VarargsConstructor(topObj); | |||
There was a problem hiding this comment.
Not to all VP systems. But if VP with some qualifier results in Lost, that qualifier probably can't be created - Lost comes from not knowing some relationship. If one can create an object of that type, one knows the relationship.
So in this system, forbidding Top makes sense.
Fixes #576