-
Notifications
You must be signed in to change notification settings - Fork 131
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
[Sealed types] Regression in instanceof check for sealed generic classes #3121
Comments
javac 23 reports:
|
Ah. See #3038 |
@nlisker - you must have also run into #3122 which I filed when playing with the test case for this ticket - that issue is resolved already while the present ticket is still being worked on for 4.34 M3. Sealed types implementation in Eclipse compiler is being completely overhauled and many problems are being fixed. I welcome you test recent builds and report defects if any. In any case when M3 arrives. Thanks. |
Possibly I did. If an error disappears after saving/cleaning/rebuilding, I tend to let it off the hook. Sometimes the types of errors that disappear after saving are due to the complexity of the project (with Maven/Gradle) and can't be reproduced with a small snippet, so it's not clear where the fault is. I keep a minimal Eclipse installation that I update to nightly builds just for testing to see if a problem I hit with my production Eclipse is still viable "in the future". By the way, as for the compiler's treatment of sealed types, I see that javac reports an error only for the |
See that Besides, a programmer way want to coalesce one type to another using instanceof and materialize a binding variable in the process, so I am not sure a warning would not be incorrect or not add noise value |
This is why I added a return if the instance is
I'm not really sure what this means, sounds like upcasting. However, the benefit of such a warning is not critical (akin to dead code), so if there are reasons not to do it, it's fine to leave it out. |
Right, I saw those observations when the defect report came in, but it faded from my memory when I wrote the recent comment. There is no null analysis based flow analysis that is defined in the language that is worth speaking of and while JDT has some infrastructure in place that has various limitations. See #3088 (https://bugs.eclipse.org/bugs/show_bug.cgi?id=538421 and its 28 duplicates(!))
|
See 5.1.6.1 Allowed Narrowing Reference Conversion ...
It is in fact in implementing this section of the JLS for #2634 that we "progressed" by fixing #2595 but "regressed" in handling the present test scenario. However, prior to #2634, we were correct only by accident. |
This program compiles with JDK23 - but that looks highly suspicious:
How can there be an instance of @stephan-herrmann - What is your take ?? |
This one is a bit tricky as there are several cases to look at in 4.32 and 4.33 (release verions).
In the following snippet there are 3
sealed
generic superclasses with 2final
subclasses. In case 1,Maybe
, one of the subclasses implements an interface; in case 2,SurelyNot
, none implement; and in case 3,SurelyYes
, both implement. Then each class is checked if it'sinstanceof
that interface:What I would expect:
false
for the 2nd case andtrue
for the 3rd (unless it's me who is not smart). This can be either a warning or an error from my point of view, but maybe it's specified.What happens:
In 4.32 everything compiles normally with no warning. This is correct if the compiler doesn't need to be smart.
In 4.33 all 3 give an error:
Incompatible conditional operand types Maybe<capture#4-of ?> and SuperInt
etc.Variations
null
checks slightly changes the analysis since nowSurelyYes
is likeMaybe
(null
doesn't implement the interface). There is no difference in the behavior.removes the error from cases 1 and 3, but leaves it on 2.
sealed
from all 3 removes the error in all 3.The text was updated successfully, but these errors were encountered: