-
Notifications
You must be signed in to change notification settings - Fork 26
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
Compile the samples
files as tests (samples-google-prototype-eisop)
#498
Compile the samples
files as tests (samples-google-prototype-eisop)
#498
Conversation
@@ -19,8 +19,10 @@ | |||
@NullMarked | |||
class ContainmentSuperVsExtendsSameType { | |||
void x() { | |||
// `conflicting_annotations` b/c upper and lower bound of `? super Object` differ. | |||
// :: error: jspecify_nullness_mismatch jspecify_but_expect_nothing |
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.
Separately, as we go through expect_nothing
and but_expect_error
messages, it would be nice to have a comment why a mismatch is expected.
Here, I expect the problem is that Lib<? super Object>
is not a subtype of Lib<? extends Object>
, right?
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.
Yes, I believe that's right.
And yes, much of the idea of the conformance-test framework is that it lets us replace "error of some kind on this line" with more of an "expected Foo but was Foo?" style.
// :: error: jspecify_nullness_mismatch jspecify_but_expect_nothing | ||
new Check<Lib<? extends Number>, Lib<? super Number>>(); | ||
// :: error: jspecify_conflicting_annotations | ||
new Check<Lib<? extends Object>, Lib<? super 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.
#485 previously changed this, but that change introduced a java compilation failure that went unnoticed.
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 is into the
samples-google-prototype-eisop
branch. Let me know if I should do something similar formain
and/orsamples-google-prototype
.
I could see doing it for main
(and then merging that into samples-google-prototype
). Maybe it will help with the conformance-test scores there?
@@ -19,8 +19,10 @@ | |||
@NullMarked | |||
class ContainmentSuperVsExtendsSameType { | |||
void x() { | |||
// `conflicting_annotations` b/c upper and lower bound of `? super Object` differ. | |||
// :: error: jspecify_nullness_mismatch jspecify_but_expect_nothing |
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.
Yes, I believe that's right.
And yes, much of the idea of the conformance-test framework is that it lets us replace "error of some kind on this line" with more of an "expected Foo but was Foo?" style.
samples
files as testssamples
files as tests (samples-google-prototype-eisop)
Doing it on I've created #501 as additional PR, to also compile the samples in the sister-branch |
Heh, oops. As soon as I saw that this thread had a new message on my phone, I suddenly realized my mistake about |
This is into the
samples-google-prototype-eisop
branch. Let me know if I should do something similar formain
and/orsamples-google-prototype
.