Summary: | isCastCompatible seems to need capture bindings now to answer correct results | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Dirk Baeumer <dirk_baeumer> |
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | P3 | CC: | gunnar, jeem, martinae, Olivier_Thomann |
Version: | 3.1 | ||
Target Milestone: | 3.1 RC3 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Dirk Baeumer
2005-06-11 07:26:42 EDT
Discussed it with Philippe, and the problem is that isCastCompatible now needs capture bindings for generics to answer correct questions. However the tests answer the question of bindings accessed from variable declaration fragments so they are not captured. We have to check what to do here. Need to be resolved within RC3 since UI ramifications. Suspect it is a consequence of our tightening the casting rule which was too permissive. Need to see whether capturing expression type would improve behavior, but clearly the situation where the compiler would perform any cast test would involve captures in place of wildcards. "TypeBinding for Vector<Object>".isCastCompatible("TypeBindig for Collection<? extends Number>" However casting Collection<? extends Number> to Vector<Object> is leagal. Actually, what the compiler sees is rather: Collection<capture-of ? extends Number> on the right hand side. I agree also that the API looks backward. +1 for RC3 Dirk - pls cast your vote. Just to clarify that I understand correcly what will be changed: - isCastCompatible will work for all sorts for type bindings again - the API will still stay backward. Are we considering deprecating the API and adding a new method which does the expected (e.g canCastTo). At least we should clarify the current API. Appropriate action still need to be determined based on results of investigation. Ideally, it would look like what you described, but need to see what is possible there. +1 Jim - can you please comment on the API looking backward ? If possible, we should fix it before too many start being impacted. The spec does feel backwards. But I think it's pretty late to be changing the signature for 3.1. I suggest imrpoving the spec to call attention to it being backwards. Ok. Suggest the following doc addition: * <p> * NOTE: The cast compatibility check performs backwards. * When testing whether type B can be cast to type A, one would use: * <code>A.isCastCompatible(B)</code> * </p> I am enclined to force a free capture on DOM cast check so as to simulate the fact that in real code, it would occur. This is the least amount of change at this stage. Note that for the offending scenario, javac rejects the code; we do accept it. According to the JLS, only provably distinct types should be causing grief to cast compatibility, and this isn't the case here due to presence of wildcards (or type variables, when captured). This is another issue which is being debated with language spec. Released fix for this situation. Locally it passes UI tests. Olivier - pls add a regression test for it. Regression test added in ASTConverter15Test.test0191 Verified using N20050616-0010 + JDT/Core HEAD |