X10

x10/io/Marshal.x10 cannot be flattened

Details

  • Number of attachments :
    0

Description

When I compile x10/io/Marshal.x10 with expression flattening enabled, I get six errors of which the following is typical: 

      [ejc] ----------
      [ejc] 1. ERROR in /Users/alpern/x10/x10.runtime/src-java/gen/x10/io/Marshal.java (at line 223)
      [ejc]     CharMarshal<java.lang.String, T> t5938 =
      [ejc]                                   ^
      [ejc] Cannot make a static reference to the non-static type T
      [ejc] ----------

Lines 219 to 236 of /Users/alpern/x10/x10.runtime/src-java/gen/x10/io/Marshal.java are:

//#line 49
final x10.
                                  io.
                                  Marshal.
                                  CharMarshal<java.lang.String, T> t184 =
                                  ((x10.
                                  io.
                                  Marshal.
                                  CharMarshal)(x10.
                                  io.
                                  Marshal.CHAR));
                                
//#line 49
final char t185 =
                                  t184.read(((x10.
                                              io.
                                              Reader)(r)));

The corresponding (unflattened) code in x10/runtime/src/java/gen/x10/io/Marshal.java is:

//#line 49
ch = x10.
                          io.
                          Marshal.CHAR.read(((x10.
                                              io.
                                              Reader)(r)));

I think the type of t184 should be x10.io.Marshal.CharMarshal rather than x10.io.Marshal.CharMarshal<java.lang.String, T>.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Bowen Alpern added a comment -

I checked in a version of the expression flattener with a work around for this bug in the form of a static final boolean called XTENLANG_2055. To reproduce this the bug, set this constant to false;

Show
Bowen Alpern added a comment - I checked in a version of the expression flattener with a work around for this bug in the form of a static final boolean called XTENLANG_2055. To reproduce this the bug, set this constant to false;
Hide
Permalink
Igor Peshansky added a comment - - edited

I've investigated this a bit. This is a subtler issue than I originally thought. To summarize: we represent containers for static methods, fields, and classes as uninstantiated types (with typeArguments()==null). When a static method or field is looked up through a concrete (instantiated) class or interface, the compiler attempts to reinstantiate the field or method, including its type, which is a nested class, and thus has an uninstantiated container. However, type parameter substitution code still treats uninstantiated types as if they had explicit type parameters, and thus substitutes the actual type arguments. Later, inner class removal code pushes the type arguments forward unconditionally, because it assumes that container types would have been instantiated only in contexts where the type parameters would be accessible.
There are two possible ways of fixing this: (1) make sure that the types are always explicitly instantiated where necessary and fix the type parameter substitution code to only consider explicit type arguments, or (2) change the reinstantiation code to avoid doing type parameter substitution on containers of static members. (1) involves a lot of code changes that have to be done on a one-by-one basis, but (2) will result in more fragile code.

Show
Igor Peshansky added a comment - - edited I've investigated this a bit. This is a subtler issue than I originally thought. To summarize: we represent containers for static methods, fields, and classes as uninstantiated types (with typeArguments()==null ). When a static method or field is looked up through a concrete (instantiated) class or interface, the compiler attempts to reinstantiate the field or method, including its type, which is a nested class, and thus has an uninstantiated container. However, type parameter substitution code still treats uninstantiated types as if they had explicit type parameters, and thus substitutes the actual type arguments. Later, inner class removal code pushes the type arguments forward unconditionally, because it assumes that container types would have been instantiated only in contexts where the type parameters would be accessible. There are two possible ways of fixing this: (1) make sure that the types are always explicitly instantiated where necessary and fix the type parameter substitution code to only consider explicit type arguments, or (2) change the reinstantiation code to avoid doing type parameter substitution on containers of static members. (1) involves a lot of code changes that have to be done on a one-by-one basis, but (2) will result in more fragile code.
Hide
Permalink
David Grove added a comment -

defer remaining 2.1.2 issues to 2.2.0

Show
David Grove added a comment - defer remaining 2.1.2 issues to 2.2.0
Hide
Permalink
David Grove added a comment -

bulk defer of open issues to 2.2.2.

Show
David Grove added a comment - bulk defer of open issues to 2.2.2.
Hide
Permalink
David Grove added a comment -

bulk defer of issues to 2.2.3.

Show
David Grove added a comment - bulk defer of issues to 2.2.3.
Hide
Permalink
David Grove added a comment -

bulk defer of 2.3.0 open issues to 2.3.1.

Show
David Grove added a comment - bulk defer of 2.3.0 open issues to 2.3.1.
Hide
Permalink
David Grove added a comment -

bulk defer to 2.3.2

Show
David Grove added a comment - bulk defer to 2.3.2
Hide
Permalink
David Grove added a comment -

Removed workaround in 25558. Verified that it was no longer needed. Problem most likely fixed by Dave C's extensive reworking of the InnerClassRemover

Show
David Grove added a comment - Removed workaround in 25558. Verified that it was no longer needed. Problem most likely fixed by Dave C's extensive reworking of the InnerClassRemover

People

  • Assignee:
    David Grove
    Reporter:
    Bowen Alpern
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: