Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 216686

Summary:

[1.5][compiler] Failures of inference and overload resolution

Product:

[Eclipse Project] JDT

Reporter:

Olivier Lefevre <lefevrol>

Component:

Core

Assignee:

Philipe Mulet <philippe_mulet>

Status:

VERIFIED FIXED

QA Contact:

Severity:

normal

Priority:

CC:

eric_jodet, kent_johnson, Olivier_Thomann

Version:

3.4

Target Milestone:

3.4 M5

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
The test case	none
Proposed patch	none

Description Olivier Lefevre

2008-01-26 21:10:54 EST

Consider the code in the attached test and the comments therein.
The first column of the table lists the 'combine' variants enabled
(the others are supposed to be commented out), the second and third
columns the outcome of the compiler invocation and the fourth one a
possible workaround in the form of a modification of the call to 
'combine' in the test method.

The case of the lone #3 is a failure of inference since it can be
be cured by a cast: both javac and ecj infer OO<String,Object> and
complain, even though it is glaringly obvious that this is also (by
inheritance) a TO<String> and therefore acceptable.

In all the other cases the ecj error is:
---------------------------------------------------------------------
1. ERROR in Bug5.java (at line 32)
        put(Integer.class, combine(FUNC2, FUNC1));
                           ^^^^^^^
The method combine(Bug5.TT, Bug5.TO<? super Object>) is ambiguous for 
the type Bug5
---------------------------------------------------------------------
which I am not sure what to make of but looks like a failure to
resolve overloaded methods. Intuitively I would say that there
is no problem here since #1 is more specialized than #2, which 
itself is more specialized than #3 and thus the lower-ranked one
should be picked and there is no ambiguity.

Moreover it seems to me that there is a contradiction in the case 
of #1+#3: since ecj considers #3 inapplicable, that leaves it with 
#1 alone and thus you would think there is no ambiguity.

Comment 1 Olivier Lefevre

2008-01-26 21:11:33 EST

Created attachment 87961 [details]
The test case

Comment 2 Philipe Mulet

2008-01-31 09:38:06 EST

Simplified testcase which should compile:

interface OO<T,E> {}
interface TO<T> extends OO<String,T> {}
interface TT extends TO<String> {}

public class X {
	<E, T> TO<T> combine(final TO<? super E> x, final OO<E, T>[] y) { return null; }
  void foo(TT tt, TO<? super Object>[] too) {
     combine(tt, too);
  }
}

Comment 3 Philipe Mulet

2008-01-31 09:46:08 EST

Added GenericTypeTest#test1269-1283

Comment 4 Philipe Mulet

2008-01-31 10:04:16 EST

Created attachment 88422 [details]
Proposed patch

There were 2 issues.

1. Tiebreak algorithm miscomputed intersection types, where no intersection was mandated in the end. This was fooling type argument containment check.

2. Type argument containment (4.5.1.1) did not allow: 
    ? super Object <= Object

   (not described in the spec, but makes sense)

Comment 5 Philipe Mulet

2008-01-31 12:48:35 EST

Released for 3.4M5.
Fixed

Comment 6 Eric Jodet

2008-02-04 06:39:53 EST

Verified for 3.4M5 using build I20080204-0010

Comment 7 Philipe Mulet

2008-02-28 07:36:21 EST

Released fix in 3.3.x maintenance branch (post 3.3.2)