Summary: | [1.5][compiler] ecj from CVS generates spurious incomprehensible error | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Andrew John Hughes <gnu_andrew> |
Component: | Core | Assignee: | Philipe Mulet <philippe_mulet> |
Status: | VERIFIED FIXED | QA Contact: | |
Severity: | blocker | ||
Priority: | P3 | CC: | mlists, tobys |
Version: | 3.2 | ||
Target Milestone: | 3.1.1 | ||
Hardware: | PC | ||
OS: | Linux | ||
Whiteboard: |
Description
Andrew John Hughes
2005-07-28 18:01:42 EDT
Could you provide exact steps to reproduce ? Yes, run a build of ecj from CVS over the generics branch of GNU Classpath: export CVS_RSH="ssh" cvs -z3 -d:ext:anoncvs@savannah.gnu.org:/cvsroot/classpath co -r generics-branch classpath ./autogen.sh && ./configure && make. Cannot connect: Could not connect to :ext:anoncvs@savannah.gnu.org:/cvsroot/classpath: I/O exception occurred: CreateProcess: ssh savannah.gnu.org -l anoncvs cvs server error=2 Hmmm... I don't see that here, it still checks out fine. The relevant files are here: http://savannah.gnu.org/cgi-bin/viewcvs/classpath/classpath/java/lang/ref/?only_with_tag=generics-branch Note the 'generics-branch' tag. compiler v_568 had the same problem. Reproduced. Simpler testcase: public class X<T> { Y first; void foo(Y<? extends T> ref) { ref.next = first == null ? ref : first; } } class Y<E> { Y<E> next; } Problem comes from the fact the conditional expression is checking types in old 1.4 fashion (operand compatibility) before attempting 1.5 (LUB), which is wrong. Added GenericTypeTest#test799. Fixed in both 3.1.1 and 3.2 streams. Until you get the fix, you may workaround the issue by inserting an extra cast: ref.nextOnQueue = first == null ? (Reference) ref : first; The patch (using latest ecj CVS) solves that error, but spawns lots of: 22. ERROR in ../external/w3c_dom/org/w3c/dom/bootstrap/DOMImplementationRegistry.java (at line 318) return isJRE11() ? null : (ClassLoader) AccessController.doPrivileged(new PrivilegedAction() { public Object run() { ClassLoader classLoader = null; try { classLoader = Thread.currentThread().getContextClassLoader(); } catch (SecurityException ex) { } return classLoader; } }); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^\ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Incompatible conditional operand types null and ClassLoader There are lots of those now, presumably because of the ordering change. Yes, I figured this regression as well. Got addressed in latest. *** Bug 101831 has been marked as a duplicate of this bug. *** Verified in I20050920-0010 for 3.2M2 Verified using M20050923-1430 for 3.1.1 |