X10
  1. X10
  2. XTENLANG-2055

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

        Hide
        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
        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
        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
        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
        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
        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
        David Grove added a comment -

        bulk defer to 2.3.2

        Show
        David Grove added a comment - bulk defer to 2.3.2
        Hide
        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
        Hide
        David Grove added a comment -

        bulk close of 2.4 resolved issues.

        Show
        David Grove added a comment - bulk close of 2.4 resolved issues.

          People

          • Assignee:
            David Grove
            Reporter:
            Bowen Alpern
          • Votes:
            0 Vote for this issue
            Watchers:
            1 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved: