Summary: | 1.5 compiler - Methods using non-generic inner types of concreted generic classes generate wrong signatures | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Steven Tamm <stamm> |
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | critical | ||
Priority: | P3 | CC: | daniel_megert |
Version: | 3.1 | ||
Target Milestone: | 3.1 RC3 | ||
Hardware: | PC | ||
OS: | Windows XP | ||
Whiteboard: |
Description
Steven Tamm
2005-06-15 16:10:52 EDT
Good find. This is another symptom of bug 98322, however the consequence is more drastic. Need to investigate for RC3. It's very much related to 98322, When I try the proposed fix for 98322, it still fails because someArguments != null, but someArguments.length == 0. I would fix both at once. Reproducing test would be: public class X<K extends X.Key> { public abstract static class Key { public abstract String getName(); } public class Holder {} X<K>.Holder foo() { return null; } static void bar() { Object o = new X<Key>().foo(); class Local<U> { X<Key>.Holder field; } } } The generic signature for 'field' gets the offending trailing '<>' incorrectly. I am enclined to think that the fix should occur in code performing the substitution (Scope) since it shouldn't rely on ParameterizedTypeBinding to clear the mess. Senders have to behave. Problem comes from a caching issue. In order to cause grief, the offending parameterized type needs to get cached before it gets used elsewhere in a visible spot where its signature would get corrupted and persisted in some classfile construct. 1) Object o = new X<Key>().foo(); performs the offending substitution from X<K>.Holder (for msg return type)into: X<Key>.Holder, and caches it. 2) class Local<U> { X<Key>.Holder field; } finds binding for 'X<Key>.Holder' already in the cache (as it treats 0 arg as if null), and thus reuses it. From thereon offending binding (and thus signature) can get persisted into a classfile. +1 for RC3 Dani - pls cast your vote. Without a fix for it, we generate bogus signatures which can break incremental compile or tooling rendering signatures. (Forgot to CC Dani) Dani - pls cast your vote. Without a fix for it, we generate bogus signatures which can break incremental compile or tooling rendering signatures. Added GenericTypeSignatureTest#test019 +1 for 3.1 RC3. Fixed The signature of the field is: // Signature: LX<LX$Key;>.Holder; instead of: // Signature: LX<LX$Key;>.Holder<>; using RC2. Verified using N20050616-0010 + JDT/Core HEAD |