Skip to content

Viewpoint test checker: lost receiver invoke poly receiver method - #1173

Open
aosen-xiong wants to merge 37 commits into
eisop:masterfrom
aosen-xiong:poly-rdq
Open

Viewpoint test checker: lost receiver invoke poly receiver method#1173
aosen-xiong wants to merge 37 commits into
eisop:masterfrom
aosen-xiong:poly-rdq

Conversation

@aosen-xiong

@aosen-xiong aosen-xiong commented Apr 5, 2025

Copy link
Copy Markdown
Collaborator

Merge #1850 first.

This updates the viewpoint test checker coverage for receiver-dependent qualifiers.

I added a test case that checks that a method with a polymorphic receiver can still be invoked when viewpoint adaptation produces @Lost. Rather than modelling this by making @Lost non-reflexive in the qualifier hierarchy, this PR keeps the normal subtype reflexivity behaviour and rejects @Lost where it is actually invalid: on assignment left-hand sides like universe type did https://github.com/opprop/universe/blob/ee75b409f57b0aaff733e0b5a3682dd2768dccc9/src/main/java/universe/UniverseVisitor.java#L228-L230.

I think this will be sound and more expressive.

@aosen-xiong
aosen-xiong marked this pull request as draft April 5, 2025 06:00
@aosen-xiong
aosen-xiong marked this pull request as ready for review May 26, 2026 03:40
Copilot AI review requested due to automatic review settings May 26, 2026 03:40

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Pull request overview

Note

Copilot was unable to run its full agentic suite in this review.

Updates the Viewpoint Test Checker’s handling of @Lost by removing its special non-reflexive subtyping rule and instead reporting a dedicated error when @Lost appears on the left-hand side of assignments.

Changes:

  • Update tests to expect the new viewpointtest.lost.lhs error for invalid assignment LHS cases.
  • Add an assignment visitor check to flag @Lost on assignment LHS.
  • Remove the custom qualifier-hierarchy override that made @Lost non-reflexive, and update @Lost documentation accordingly.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.

Show a summary per file
File Description
framework/tests/viewpointtest/VarargsConstructor.java Adjusts expected error annotations in varargs constructor test.
framework/tests/viewpointtest/TestGetAnnotatedLhs.java Updates expected errors to include viewpointtest.lost.lhs on assignments.
framework/tests/viewpointtest/LostNonReflexive.java Updates expectations and adds a method/use-site to exercise new behavior.
framework/src/test/java/viewpointtest/quals/Lost.java Updates @Lost Javadoc to reflect new semantics (invalid as assignment LHS).
framework/src/test/java/viewpointtest/ViewpointTestVisitor.java Adds LHS assignment check for @Lost.
framework/src/test/java/viewpointtest/ViewpointTestQualifierHierarchy.java Removes the non-reflexive @Lost subtyping override.

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Comment thread framework/src/test/java/viewpointtest/ViewpointTestVisitor.java Outdated
Comment thread framework/src/test/java/viewpointtest/ViewpointTestVisitor.java Outdated
@aosen-xiong aosen-xiong removed their assignment May 26, 2026
@aosen-xiong
aosen-xiong requested a review from Copilot May 26, 2026 04:13

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Pull request overview

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Comment thread framework/src/test/java/viewpointtest/ViewpointTestVisitor.java Outdated
Comment thread framework/src/test/java/viewpointtest/quals/Lost.java Outdated
Comment thread framework/src/test/java/viewpointtest/ViewpointTestVisitor.java Outdated

@wmdietl wmdietl left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Thanks!

Comment thread framework/src/test/java/viewpointtest/ViewpointTestVisitor.java Outdated
@wmdietl wmdietl assigned aosen-xiong and unassigned wmdietl May 28, 2026
@aosen-xiong
aosen-xiong requested a review from Copilot June 10, 2026 16:20

Copilot AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@aosen-xiong aosen-xiong assigned wmdietl and unassigned aosen-xiong Jun 17, 2026
@wmdietl

wmdietl commented Jul 16, 2026

Copy link
Copy Markdown
Member

@aosen-xiong CI is failing.

@aosen-xiong

Copy link
Copy Markdown
Collaborator Author

@aosen-xiong CI is failing.

Yeah, I recently found out that a better strategy is to merge #1850 first. So I unassigned you from this one.

@aosen-xiong aosen-xiong removed their assignment Jul 31, 2026
aosen-xiong and others added 5 commits August 5, 2026 12:34
The viewpoint test checker obtained method type parameter bounds through
AnnotatedTypeFactory#methodTypeVariablesFromUse, which fetched the raw
bounds and then viewpoint-adapted them itself. "Use adapted bounds for
method/constructor type arguments" (eisop#1850) performs that adaptation in
AbstractViewpointAdapter#viewpointAdaptMethod and
#viewpointAdaptConstructor, so the framework method duplicated it.

Remove methodTypeVariablesFromUse and its BaseTypeVisitor call site,
which restores the master implementation, and read the already-adapted
bounds from methodFromUse and constructorFromUse. Constructor
invocations are now checked as well; previously only method invocations
reported viewpointtest.lost.in.bounds. Update the expectations in the
tests added by eisop#1850, and delete ViewpointAdaptationBounds.java, whose
cases those tests cover.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
ViewpointTestQualifierHierarchy overrode isSubtypeQualifiers to make
@lost non-reflexive. That override was removed in "Check lost qualifier
on assignment LHS", leaving a subclass whose constructor only forwards
to NoElementQualifierHierarchy.

AnnotatedTypeFactory#createQualifierHierarchy already returns a
NoElementQualifierHierarchy constructed with the same arguments, so
delete the class along with the createQualifierHierarchy override that
was its only caller.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@lost participates in subtyping like any other qualifier in this test
checker; the test exercises the positions where @lost is rejected, such
as assignment targets and parameters. The old name described the
qualifier hierarchy specialization that this branch removes.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
@wmdietl

wmdietl commented Aug 27, 2026

Copy link
Copy Markdown
Member

I've reviewed this PR. Since #1850 is now merged, this PR's approach of making @Lost reflexive and verifying its invalid positions (e.g., assignment LHS, parameter bounds) via commonAssignmentCheck in the Viewpoint Test Checker is sound and perfectly matches how receiver-dependent qualifiers (like those in Universe types) should behave.

I've also gone ahead and pulled in master and pushed the merge to this PR's branch so it's fully up to date and ready for merging!

@wmdietl

wmdietl commented Aug 27, 2026

Copy link
Copy Markdown
Member

@aosen-xiong Should the PR have a more general title? It seems to change a lot more than the title implies.

If the receiver parameter is Poly and the actual receiver is Lost, is the call allowed? Would this result in an error, because Lost would be assigned to Lost?

@aosen-xiong

Copy link
Copy Markdown
Collaborator Author

@aosen-xiong Should the PR have a more general title? It seems to change a lot more than the title implies.

Okay, I will update the title and description.

If the receiver parameter is Poly and the actual receiver is Lost, is the call allowed? Would this result in an error, because Lost would be assigned to Lost?

Right, I think the poly qualifier needs to be resolved first before checking if lost is part of the signature. I will fix it.

@aosen-xiong aosen-xiong assigned aosen-xiong and unassigned wmdietl Aug 27, 2026
@wmdietl

wmdietl commented Aug 28, 2026

Copy link
Copy Markdown
Member

If the receiver parameter is Poly and the actual receiver is Lost, is the call allowed? Would this result in an error, because Lost would be assigned to Lost?

Right, I think the poly qualifier needs to be resolved first before checking if lost is part of the signature. I will fix it.

If we have a getter @Poly Object getF(@Poly C this) { return this.f; } is an invocation on a @Lost C okay? The result will also be @Lost, but that seems okay. So forbidding for this case seems too strict, but maybe there are other cases where allowing a call would be unsound.
The formalization would be really useful to guide the right checks here.

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.

3 participants