Bug 364672 - [compiler] ecj fails to compile valid calls to varargs method
Summary: [compiler] ecj fails to compile valid calls to varargs method
Status: VERIFIED FIXED
Alias: None
Product: JDT
Classification: Eclipse Project
Component: Core (show other bugs)
Version: 3.8   Edit
Hardware: All All
: P3 major (vote)
Target Milestone: 3.8 M4   Edit
Assignee: Srikanth Sankaran CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-11-24 01:23 EST by Ayushman Jain CLA
Modified: 2011-12-05 10:15 EST (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ayushman Jain CLA 2011-11-24 01:23:14 EST
HEAD

X.java
---------------%<--------------
package snippet;
public class X {
			private class Z {} 
			public void foo() {
					Z[] zs = null;
					Y.bar(zs, new Z());
			}
			public static void main(String[] args) {}
}

Y.java
--------------%<------------------
public class Y {
			public native static <T> void bar(T[] t, T t1, T... t2);
}


This fails to compile after the fix for bug 346042. There are also some missing code implementation errors such as this:

public class X {
	public static final String CONSTANT = "";
	private static class A {
		A(String s, String s2, String s3, A... a) {}
	}
	private static class B extends A {
		B(String s, String s2) {
			super(s, s2, CONSTANT);
		}
	}
	private static void foo(Object o, A ... a) {
	}
	private static B bar() {
		return null;
	}
	public static void main(String[] args) {
		Object o = null;
		foo(o, bar(), bar());
	}
}
Comment 1 Srikanth Sankaran CLA 2011-11-24 04:25:59 EST
Fix & tests released in 3.8 stream for M4 via commit id: 0cdfad471234fb0caaef062f9838420246a133df.

Many thanks to Olivier for reporting, triaging and the patch which was
released via the above commit id.

There were two problems with the fix for bug 346042. There is some code
path between method resolution and constructor resolution. The fix for
bug 346042 made some changes in the common code path and followed it up
with suitable changes on the method resolution path after they fork.
The corresponding change was missing in the constructor resolution path
after the fork resulting in one of the issues.

The other issue is due to this landmine:

org.eclipse.jdt.internal.compiler.lookup.ReferenceBinding.canBeSeenBy(PackageBinding) reads:

/**
 * Answer true if the receiver is visible to the invocationPackage.
 */
public final boolean canBeSeenBy(PackageBinding invocationPackage) {
	if (isPublic()) return true;
	if (isPrivate()) return false;

	// isProtected() or isDefault()
	return invocationPackage == this.fPackage;
}

which does patently wrong things in some cases. I'll follow up this 
with another defect to have this code investigated.
Comment 2 Srikanth Sankaran CLA 2011-11-24 04:29:42 EST
(In reply to comment #1)

> which does patently wrong things in some cases. I'll follow up this 
> with another defect to have this code investigated.

https://bugs.eclipse.org/bugs/show_bug.cgi?id=364690 raised.
Comment 3 Satyam Kandula CLA 2011-12-05 10:15:32 EST
Verified for 3.8M4 using build I20111202-0800