Review request for OPENJDK6-40: OpenJDK6-b32 does not compile the testcase that Oracle JDK 6u45 compiles fine

[Andrew Hughes]

----- Original Message -----
> resending to the right mail thread:
> 
> 
> Hi Andrew and all,
> 
> I am about to push this change for Nikolay.
> Given that last time we had a bit of discussion on the right format of
> putback message, i want to check with you this the following is fine.
> Please check the text below and tell me if you see any issues.

The main thing that concerns me is the loss of the original author
information, but I'm not sure if we have a solution for this as yet.
I tend to go with the original author as the changeset author
(hg commit --user <username>) but that also has the downside of
not crediting the backporter.

I guess both it and the original reviewer could be looked up via
the changeset in 7, which is:

6938454: Unable to determine generic type in program that compiles under Java 6
Summary: a redundant dubtyping check causes spurious inference failure
Reviewed-by: jjg

I think that's meant to be 'subtyping' ;)

> According to Nikolay, this fix is not a strightforward port but a
> reworked fix for the 7's 6938454.
> 

I hadn't realised this. Is there a reason the following hunks are absent?

diff -r ed354a00f76b -r 36c4ec4525b4 src/share/classes/com/sun/tools/javac/comp/Attr.java
--- a/src/share/classes/com/sun/tools/javac/comp/Attr.java	Tue Jul 27 11:52:11 2010 -0700
+++ b/src/share/classes/com/sun/tools/javac/comp/Attr.java	Thu Jul 29 15:56:25 2010 +0100
@@ -1694,8 +1694,22 @@
             //if the type of the instance creation expression is an interface
             //skip the method resolution step (JLS 15.12.2.7). The type to be
             //inferred is of the kind <X1,X2, ... Xn>C<X1,X2, ... Xn>
-            clazztype = new ForAll(clazztype.tsym.type.allparams(),
-                    clazztype.tsym.type);
+            clazztype = new ForAll(clazztype.tsym.type.allparams(), clazztype.tsym.type) {
+                @Override
+                public List<Type> getConstraints(TypeVar tv, ConstraintKind ck) {
+                    switch (ck) {
+                        case EXTENDS: return types.getBounds(tv);
+                        default: return List.nil();
+                    }
+                }
+                @Override
+                public Type inst(List<Type> inferred, Types types) throws Infer.NoInstanceException {
+                    // check that inferred bounds conform to their bounds
+                    infer.checkWithinBounds(tvars,
+                           types.subst(tvars, tvars, inferred), Warner.noWarnings);
+                    return super.inst(inferred, types);
+                }
+            };
         } else {
             //if the type of the instance creation expression is a class type
             //apply method resolution inference (JLS 15.12.2.7). The return type

diff -r ed354a00f76b -r 36c4ec4525b4 src/share/classes/com/sun/tools/javac/comp/Infer.java
--- a/src/share/classes/com/sun/tools/javac/comp/Infer.java	Tue Jul 27 11:52:11 2010 -0700
+++ b/src/share/classes/com/sun/tools/javac/comp/Infer.java	Thu Jul 29 15:56:25 2010 +0100
@@ -458,7 +457,7 @@
 
     /** check that type parameters are within their bounds.
      */
-    private void checkWithinBounds(List<Type> tvars,
+    void checkWithinBounds(List<Type> tvars,
                                    List<Type> arguments,
                                    Warner warn)
         throws InvalidInstanceException {

Do the new tests added by the change pass?

> Thanks,
> 
> Ivan
> 
> 6938454: Unable to determine generic type in program that compiles under
> Java 6
> Reviewed-by: aph
> Contributed-by: nikgor <nikolay at azulsystems.com>
> 
> 
> 
> On 11/12/2014 22:01, Andrew Haley wrote:
> > On 12/11/2014 06:59 PM, Nikolay Gorshkov wrote:
> >> Me and my colleagues have a consensus that the patch is important to us -
> >> we are responsible for introducing a regression into OpenJDK 6 (breaking
> >> Apache Flume 1.5.0 compilation), and so we have to fix it. We have already
> >> included this patch into our OpenJDK 6 -based products, and now we are
> >> interested in upstreaming it to OpenJDK 6 itself to minimize the
> >> difference
> >> in codebase.
> > Reluctantly, OK.  I am crossing my fingers and hoping that this
> > is the last we'll see of this bug!  We shall see.
> >
> > Thanks for your patience,
> > Andrew.
> >
> >
> 
> 

Thanks,
-- 
Andrew :)

Free Java Software Engineer
Red Hat, Inc. (http://www.redhat.com)

PGP Key: 248BDC07 (https://keys.indymedia.org/)
Fingerprint = EC5A 1F5E C0AD 1D15 8F1F  8F91 3B96 A578 248B DC07