Bug 167268

Summary:

[1.5][compiler] Phantom erasure collision error.

Product:

[Eclipse Project] JDT

Reporter:

Ed Merks <Ed.Merks>

Component:

Core

Assignee:

Philipe Mulet <philippe_mulet>

Status:

VERIFIED DUPLICATE

QA Contact:

Severity:

normal

Priority:

CC:

give.a.damus

Version:

3.3

Target Milestone:

3.2.2

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
The project that illustrates the problem.	none

Description Ed Merks

2006-12-08 14:10:07 EST

I'll attach the test case that demonstrates the problem I'm seeing in I20061129-1340.  The test case compiles fine from scratch or if you clean it, but if you go to ExampleFactoryImpl.createCrazy and change it by adding a blank line into the method, an error comes up saying

Name clash: The method createCrazy() of type ExampleFactoryImpl has the same erasure as createCrazy() of type ExampleFactory but does not override it.

This error is bogus since the method signature is identical to the one in the interface.

Comment 1 Ed Merks

2006-12-08 14:11:43 EST

Created attachment 55330 [details]
The project that illustrates the problem.

Comment 2 Christian Damus

2006-12-08 14:41:54 EST

This is happening in the I20051205-1200 build, too.

Comment 3 Olivier Thomann

2006-12-08 14:59:38 EST

Added disabled regression test in org.eclipse.jdt.core.tests.compiler.regression.GenericTypeTest#test1094.

Right now we report:
----------
1. ERROR in D:\tests_sources\example\src\ExampleFactoryImpl.java (at line 1)
	public class ExampleFactoryImpl implements ExampleFactory {
	             ^^^^^^^^^^^^^^^^^^
The type ExampleFactoryImpl must implement the inherited abstract method ExampleFactory.createCrazy()
----------
2. ERROR in D:\tests_sources\example\src\ExampleFactoryImpl.java (at line 2)
	public <O extends Other, T extends O> Crazy<O, T> createCrazy() {
	                                                  ^^^^^^^^^^^^^
Name clash: The method createCrazy() of type ExampleFactoryImpl has the same erasure as createCrazy() of type ExampleFactory but does not override it
----------

javac 1.5.0 compiles it fine.

Comment 4 Olivier Thomann

2006-12-08 15:07:07 EST

Also fails with 3.2.0 and 3.2.1.
This is not a regression.

Comment 5 Kent Johnson

2006-12-08 15:55:43 EST

The problem is at the end of BinaryTypeBinding.initializeTypeVariable() :

var.superInterfaces = bounds == null ? Binding.NO_SUPERINTERFACES : bounds;
if (firstBound == null) {
  firstBound = var.superInterfaces.length == 0 ? null : var.superInterfaces[0];
  var.modifiers |= ClassFileConstants.AccInterface; <<<<
}
var.firstBound = firstBound;


In the source case, we do not tag the modifiers with AccInterface when the firstBound is an interface.

Why are we doing it here?

When should a TypeVariableBinding think its an interface?

Comment 6 Kent Johnson

2006-12-11 16:21:10 EST

Another case of bug 162991

*** This bug has been marked as a duplicate of bug 162991 ***

Comment 7 Maxime Daniel

2007-01-10 12:15:34 EST

Activated GenericTypeTest#test1094 in HEAD and released it in R3_2_maintenance stream.

Comment 8 Eric Jodet

2007-01-16 03:40:00 EST

verified for 3.2.2 using build M20070112-1200