-
Notifications
You must be signed in to change notification settings - Fork 125
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
[23] exhaustiveness signalling difference between javac and ecj #2915
Comments
|
@stephan-herrmann, I expected this question :) |
Firstly this seems to apply (14.11.1.1):
Thus While the difference between "covers" and "unconditional" seems indeed to be This sounds like the spec is saying:
There are other places in the spec saying "A default label is permitted, but not required, when ...", so the spec "prefers" unnecessary Sounds like a good question for the EG ... but for now ecj needs to be corrected. |
+ precise implementation of TypePattern.isUnconditional() + defer setting SwitchStatement.totalPattern until we know if a default case is present (otherwise we would generated inconsistent code for default). fixes eclipse-jdt#2915
@mpalat for the fix I had to provide a more precise implementation of Additionally, I'm surprised that the definition of "unconditional" doesn't seem to consider presence of a guard. Did you find a connection between these somewhere? Or is that supposed to be evident from the word "unconditional"? |
I see the following statement in section 14.11.1 which provides a connection between unguarded and unconditional: A case label with a case pattern that is unconditional for the type of the selector expression will, as the name suggests, match every value and so behave like a default label. A switch block can not have more than one switch label that acts like a default." That said, the following is not spelt out explicitly in case of guarded pattern, but may have to be deduced:
[thinking wild :) - more involved cases - when the conditional covers all possibilities ie eg: all values of ints are covered - we may not be able to do this analysis at compile time - these are anyway not expected to be spelt out in spec] |
Yes, believe so. |
So, in this situation JLS requires that a case be both unguarged and unconditional, suggesting that these are independent concepts. Ergo: |
For posterity: our concept of a "total pattern" ( This should not be confused with
In 14.11.1 this sentence is typeset in italics, which implies that it only serves to explain a situation that should already be defined by other parts of the spec (it's "non-normative"). This might indicate that the errors we report via
I'm removing
|
+ precise implementation of TypePattern.isUnconditional() + defer setting SwitchStatement.totalPattern until we know if a default case is present (otherwise we would generated inconsistent code for default). fixes eclipse-jdt#2915
+ clarify that flagDuplicateDefault() flags only conditionally, renamed to checkDuplicateDefault() - inside this method clarify that only one error is reported per loc. + remove all conflict reporting from CaseStatement.resolveCasePattern - will be done within SwitchStatement.resolve() anyway + remove IProblem.DuplicateTotalPattern and related code - all errors reported here coincided with a dominance error + adjust tests: no longer expect secondary errors fixes eclipse-jdt#2915
+ precise implementation of TypePattern.isUnconditional() - remove implementations in parent / sibling classes + defer setting SwitchStatement.totalPattern until we know if a default case is present (otherwise we would generated inconsistent code for default). + clarify that flagDuplicateDefault() flags only conditionally, renamed to checkDuplicateDefault() - inside this method clarify that only one error is reported per loc. + remove all conflict reporting from CaseStatement.resolveCasePattern - will be done within SwitchStatement.resolve() anyway + remove IProblem.DuplicateTotalPattern and related code - all errors reported here coincided with a dominance error + adjust tests: no longer expect secondary errors fixes #2915
Closed via #2925 |
Given,
ecj bails out with the error:
"Switch case cannot have both unconditional pattern and default label"
while javac compiles.
Further, spec says -
Section 5.7.2 says - "Unconditional exactness is used at compile time to check the dominance of one pattern over another in a switch block (14.11.1), and whether a switch block as a whole is exhaustive (14.11.1.1)."
and also, includes "a boxing conversion" for unconditionally exact. However, this is an unboxing condition [from Integer to int] and not a boxing conversion -and hence not unconditionally exact. and hence it looks like ecj should allow this - ie, should not consider "case int i" as covering Integer.
But, what could be a value of myInt such that default is taken instead of case int i? @stephan-herrmann any thoughts on this?
The text was updated successfully, but these errors were encountered: