Uploaded image for project: 'JDK'
  1. JDK
  2. JDK-8054721

18.4: Clean up resolution of capture ivars



      As specified, resolution does some incorrect things when it attempts to resolve capture ivars (that is, ivars that are introduced by a "capture bound").

      1) Capture must not produce a variable with bounds that come from a downstream assignment, the way resolution does it (e.g., given 'C<z1> = capture(C<?>)' and 'C<z1> --> C<? extends String>', resolving 'z1 = CAP extends String'). The only valid bounds for the capture variable are the wildcard bound and declaration-site bound.

      2) There can be dependency cycles that mix capture ivars and normal ivars (e.g., given 'C<z1> = capture(C<? extends t>)', with some ivar u appearing in the target type, z1 -> t -> u -> z1). We can't just resolve them all at once; we must break the cycle somehow.

      3) In the case of a cycle, where there is an unresolved non-wildcard capture ivar (e.g., z2 in the bound 'C<z1,z2> = capture(C<?,T>)'), it's incorrect to generate a new capture variable for z2. We must resolve it to T (whatever type that represents).

      The picture that emerges is that we ought to be doing something that looks like: i) resolve all ivars in the to-be-captured part of the capture bound (and maybe some of their dependencies, breaking the cycle somewhere further on?); ii) perform a _real_ capture to get valid instantiations for the capture ivars; iii) continue with resolution.

      An example of a cycle:
      <T> C<?,T> makeC();
      <U> void take(C<? extends u, ? extends u> arg);
      // C<z1,z2> = capture(C<?,t>)
      // z1 -> t -> u -> z1


          Issue Links



              • Assignee:
                dlsmith Dan Smith
                dlsmith Dan Smith
              • Votes:
                0 Vote for this issue
                1 Start watching this issue


                • Created: