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.

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

Set var arg type before calling viewpointAdaptConstructor #783

Merged
merged 8 commits into from
Jun 23, 2024

Conversation

Ao-senXiong
Copy link
Member

Fixes #777

Copy link
Member

@wmdietl wmdietl left a comment

Choose a reason for hiding this comment

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

Thanks!

framework/tests/viewpointtest/VarargType.java Outdated Show resolved Hide resolved
framework/tests/viewpointtest/VarargType.java Outdated Show resolved Hide resolved
@wmdietl wmdietl assigned Ao-senXiong and unassigned wmdietl Jun 20, 2024
@Ao-senXiong Ao-senXiong requested a review from wmdietl June 20, 2024 19:21
Copy link
Member

@wmdietl wmdietl left a comment

Choose a reason for hiding this comment

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

Having one passing and one failing test with actual viewpoint adaptation would give us much more confidence that the problem is actually fixed.

@@ -0,0 +1,27 @@
import viewpointtest.quals.*;
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 add the usual starter text with a link to the issue that this test is for?

Copy link
Member

Choose a reason for hiding this comment

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

Tests that actually use some annotations would be nice.

Copy link
Member Author

Choose a reason for hiding this comment

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

Can you add the usual starter text with a link to the issue that this test is for?

Done

Tests that actually use some annotations would be nice.

Done

@@ -0,0 +1,27 @@
import viewpointtest.quals.*;

public class VarargType {
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 Type in the class name referring to?

Copy link
Member Author

Choose a reason for hiding this comment

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

changed it to VarargsConstructor.


// inner class
class Inner {
Inner(String str, Object... args) {}
Copy link
Member

Choose a reason for hiding this comment

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

How about only the varargs parameter and then test with:

  • new Inner()
  • new Inner(new Object())
  • Varargtype.this.new Inner()
  • Varargtype.this.new Inner(new Object())

To test more of the tricky combinations with inner classes.

Copy link
Member Author

Choose a reason for hiding this comment

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

Added.


// anonymous class
Object o =
new Object() {
Copy link
Member

Choose a reason for hiding this comment

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

This doesn't test that the varargs constructor can be used to create an anonymous class. It should be something like new VarargType(...) { /* either nothing or some code */ }

Copy link
Member Author

Choose a reason for hiding this comment

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

Okay, thanks!


VarargsConstructor(String str, Object... args) {}

@SuppressWarnings({"inconsistent.constructor.type", "super.invocation.invalid"})
Copy link
Member Author

Choose a reason for hiding this comment

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

@wmdietl I feel like this is also happening when annotate the constructor in here

@SuppressWarnings({"inconsistent.constructor.type", "super.invocation.invalid"})
.

can you share some insight on these two error messages?

Copy link
Member

Choose a reason for hiding this comment

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

Do the full error messages not explain the errors well enough?
1.) Constructor type (%s) is a subtype of the top type (%s), therefore it cannot be statically verified. We cannot statically ensure that the constructor creates an object of a non-top type. Therefore, any constructor that is annotated with something non-top produces this.
2.) Constructor of type %s cannot call %s of type %s. The constructor from the superclass has the default annotation. The super constructor is implicitly called and this constructor has a different annotation - therefore, we get a warning about the mismatch.

Please open PRs to improve these error messages if something is unclear.

I notice that for these two errors there is no explanation in docs/manual.
We could improve our checks to:
1.) produce a list of all unique error keys from the messages.properties files.
2.) ensure each key appears somewhere in docs/manual. Ideally, outside of just a code example (e.g. one of the two error keys appears once as @SuppressWarnings("super.invocation.invalid"). Is that good enough as documentation?)
3.) ensure each key appears somewhere in the checker source code, to avoid that we have dead error messages in messages.properties files.
4.) ensure each key appears in at least one test case as expected error.

I'm not sure how well-covered the manual is currently for the error keys, but this looks like a nice goal to reach.
If this sounds useful, please convert this comment into an issue.

@Ao-senXiong Ao-senXiong requested a review from wmdietl June 21, 2024 03:15
@Ao-senXiong Ao-senXiong assigned wmdietl and unassigned Ao-senXiong Jun 21, 2024
Copy link
Member

@wmdietl wmdietl left a comment

Choose a reason for hiding this comment

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

Thanks for the expansion!


VarargsConstructor(String str, Object... args) {}

@SuppressWarnings({"inconsistent.constructor.type", "super.invocation.invalid"})
Copy link
Member

Choose a reason for hiding this comment

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

Do the full error messages not explain the errors well enough?
1.) Constructor type (%s) is a subtype of the top type (%s), therefore it cannot be statically verified. We cannot statically ensure that the constructor creates an object of a non-top type. Therefore, any constructor that is annotated with something non-top produces this.
2.) Constructor of type %s cannot call %s of type %s. The constructor from the superclass has the default annotation. The super constructor is implicitly called and this constructor has a different annotation - therefore, we get a warning about the mismatch.

Please open PRs to improve these error messages if something is unclear.

I notice that for these two errors there is no explanation in docs/manual.
We could improve our checks to:
1.) produce a list of all unique error keys from the messages.properties files.
2.) ensure each key appears somewhere in docs/manual. Ideally, outside of just a code example (e.g. one of the two error keys appears once as @SuppressWarnings("super.invocation.invalid"). Is that good enough as documentation?)
3.) ensure each key appears somewhere in the checker source code, to avoid that we have dead error messages in messages.properties files.
4.) ensure each key appears in at least one test case as expected error.

I'm not sure how well-covered the manual is currently for the error keys, but this looks like a nice goal to reach.
If this sounds useful, please convert this comment into an issue.

framework/tests/viewpointtest/VarargsConstructor.java Outdated Show resolved Hide resolved
framework/tests/viewpointtest/VarargsConstructor.java Outdated Show resolved Hide resolved
framework/tests/viewpointtest/VarargsConstructor.java Outdated Show resolved Hide resolved
framework/tests/viewpointtest/VarargsConstructor.java Outdated Show resolved Hide resolved
@wmdietl wmdietl assigned Ao-senXiong and unassigned wmdietl Jun 21, 2024
@Ao-senXiong
Copy link
Member Author

Submitted a new issue for error key coverage #789 .

@Ao-senXiong Ao-senXiong requested a review from wmdietl June 21, 2024 22:41
@Ao-senXiong Ao-senXiong assigned wmdietl and unassigned Ao-senXiong Jun 22, 2024
@wmdietl wmdietl changed the title Set var arg type before calling viewpointAdaptorConstructor Set var arg type before calling viewpointAdaptConstructor Jun 23, 2024
Copy link
Member

@wmdietl wmdietl left a comment

Choose a reason for hiding this comment

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

Thanks!

@wmdietl wmdietl merged commit 4d8d1a5 into eisop:master Jun 23, 2024
39 checks passed
Ao-senXiong added a commit to Ao-senXiong/checker-framework that referenced this pull request Jun 23, 2024
Co-authored-by: Werner Dietl <wdietl@gmail.com>
Ao-senXiong added a commit to Ao-senXiong/checker-framework that referenced this pull request Jun 25, 2024
Co-authored-by: Werner Dietl <wdietl@gmail.com>
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.

CF crashes in ViewpointTestChecker when calling a varargs constructor
2 participants