A sealed interface with generic causes IllegalStateException #3024
Conversation
srikanth-sankaran
force-pushed
the
Issue3009
branch
3 times, most recently
from
053778b
to
4ae6d20
Compare
srikanth-sankaran
force-pushed
the
Issue3009
branch
2 times, most recently
from
fef19a0
to
48c83fd
Compare
can be done then * Fixes eclipse-jdt#3009
srikanth-sankaran
force-pushed
the
Issue3009
branch
from
48c83fd
to
3e6c7aa
Compare
There was a problem hiding this comment.
@srikanth-sankaran some questions fyi.
Generally, we seem to be converging based on the understanding that no unchecked cast is allowed and hence all type parameters not determined from the super type must be substituted with wildcards, indeed.
| do { | ||
| if (current.kind() == Binding.GENERIC_TYPE) { | ||
| for (TypeVariableBinding tvb : current.typeVariables()) { | ||
| map.put(tvb, null); |
There was a problem hiding this comment.
How would anyone observe the effect of this put()?
There was a problem hiding this comment.
How would anyone observe the effect of this put()?
Isn't it more pertinent to ask "How would anyone observe the effect of this do while loop?" :)
So yes it would seem the entire enclosing do {} while could be gotten rid of - which I will do along with anymore follow up actions on behalf of #3038
There was a problem hiding this comment.
How would anyone observe the effect of this put()?
PR #3149 addresses this review comment, thanks!
|
|
||
| // Step 2: Collect substitutes | ||
| current = this; | ||
| TypeBinding sooper = pt.findSuperTypeOriginatingFrom(this); |
There was a problem hiding this comment.
Splendid naming! 🤣
| if (current.isParameterizedType()) { | ||
| for (int i = 0, length = sooper.typeArguments().length; i < length; i++) { | ||
| TypeBinding t = sooper.typeArguments()[i]; | ||
| if (t instanceof TypeVariableBinding tvb) { |
There was a problem hiding this comment.
This would also capture capture bindings (pun intended), but super types aren't captured, right?
So what would happen when a wildcard is used? Should you need to call isTypeArgumentContainedBy() instead of testing equality?
There was a problem hiding this comment.
This would also capture capture bindings (pun intended), but super types aren't captured, right? So what would happen when a wildcard is used? Should you need to call
isTypeArgumentContainedBy()instead of testing equality?
I don't know. Let me know if you are able to construct a test case - we could address any issues in #3038
Great! Forbidding unchecked casts intuitively make complete sense since control flow may enter the associated block with the wrong type otherwise. Your reference to 14.30.3 and 5.7 elsewhere is bang on as far as the unchecked cast is concerned - thanks. WRT #2656 - I seem to have anticipated the introduction of a new context - the testing context - I had named it |
|
Generally speaking it hurts that we have poor coverage here. The present implementation of PTB.permittedTypes() uses observed substitutes as being the SAME as the type variables... (my vocabulary may be loose) |
To make matters complicated we have a regression in unchecked cast reporting - see #1802 that causes some problems in this area: #1735 |
+ uses findSubtypeCorrespondingTo() extracted from eclipse-jdt#3024
What it does
Author checklist