Summary: | [1.5] [compiler] JDT Internal Exception under import circularity | ||||||||
---|---|---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Greg Gibeling <gdgib> | ||||||
Component: | Core | Assignee: | Kent Johnson <kent_johnson> | ||||||
Status: | VERIFIED FIXED | QA Contact: | |||||||
Severity: | normal | ||||||||
Priority: | P3 | CC: | philippe_mulet | ||||||
Version: | 3.2.1 | ||||||||
Target Milestone: | 3.2.2 | ||||||||
Hardware: | PC | ||||||||
OS: | Windows XP | ||||||||
Whiteboard: | |||||||||
Attachments: |
|
Description
Greg Gibeling
2006-11-07 11:23:42 EST
The latter could be a side effect of the ClassCastException. Can you provide steps to recreate ? I can provide a tarball/zipfile of code to recreate the problem mentioned at the end of the first comment as that is easy and darn near deterministic. But I can't easily recreate exactly that exception since it seems to be a nondeterministic side effect of build order. If you'd like a tarball or zipfile to create the later problem, just let me know an e-mail address. It's code I'd rather not post to bugzilla for now. Please send it to me. Got the file, thanks. Using the files you sent, I do not get the exception, but I get the error you mention in the accompanying note, by following the given steps. Thanks again for sharing. I'll try to forge a smaller test case, and I'll investigate the causes. If the exception for which you initially opened the bug shows up again, please let us know steps to reproduce (as far as isolating those can be done). The issue is around the resolution of ParameterizedTypeBinding-s when the generic type happens to be unresolved (yet). The method used to break the recursion marks the type has not having unresolved parameters... which happens to be interpreted down the path as not having parameters at all. Then the result is not generic, hence the message. (This has been observed by stepping through code with 3.2 maintenance code. Need to write a test case and to assess its behavior on 3.2 and 3.3.) The initial exception hasn't shown up again quite the same way, but it's been exhibiting the same characteristics as the error you desribed. I'll try to get a smaller test case together when I have some time to work on it, but it might be a while. The problem is a bit more involved than what I thought initially. My current understanding is the following: - BinaryTypeBinding#BinaryTypeBinding(PackageBinding, IBinaryType, LookupEnvironment) delegates to BinaryTypeBinding#cachePartsFrom the proper initialization of the type variables for the newly created binding; it puts it to null to signal that it is not properly initialized yet; (amongst other things, this avoids being considered as non generic); - BinaryTypeBinding#cachePartsFrom starts by setting typeVariables to NO_TYPE_VARIABLES, to protect the case where something goes wrong before the resolution is complete; this is generally harmless... - except in this case where the resolution of the type parameters themselves involve the current type itself, which is the case here; when the type is returned by the cache by the standard mechanism, it is then marked as non generic - because it has NO_TYPE_VARIABLES - and fails to satisfy the needs of the calling point. The clean build does not involve those binary bindings and keeps safe. Released (inactive) GenericTypeTest#1075 that illustrates the problem on a much smaller source: public class X <T extends X<?>.J>{ public class J implements I<T> { } } public interface I <T> { } public class Y extends X { } Compiled altogether, Y behaves correctly. Compiled alone against X.class and I.class, it fails with the following message: 1. ERROR in Y.java (at line 1) public class Y extends X { ^ The type X is not generic; it cannot be parameterized with arguments <?> Note that this is probably only one of the problems that you have met. Moving to Philippe for the BinaryTypeBinding issue. If the fix is simple, can we backport it for 3.2.2 ? +1 for 3.2.2 Created attachment 54422 [details] Philippe - proposed patch to HEAD for the case described in comment #8 Created attachment 54423 [details]
Patch for 3.2.x stream
Added GenericTypeTest 1090 Released for 3.3M4 Released for 3.2.2 Enabled inactive test1075() and removed test1090() Verified for 3.3M4 with I20061212-0010. Verified for 3.2.2 using build M20060112-1200. |