-
Notifications
You must be signed in to change notification settings - Fork 16
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
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
There was a problem hiding this 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.*; |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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 { |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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) {} |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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() { |
There was a problem hiding this comment.
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 */ }
There was a problem hiding this comment.
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"}) |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this 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"}) |
There was a problem hiding this comment.
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.
Co-authored-by: Werner Dietl <wdietl@gmail.com>
Submitted a new issue for error key coverage #789 . |
viewpointAdaptorConstructor
viewpointAdaptConstructor
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks!
Co-authored-by: Werner Dietl <wdietl@gmail.com>
Co-authored-by: Werner Dietl <wdietl@gmail.com>
Fixes #777