RFR 8170667: ClassReader assigns method parameters from MethodParameters incorrectly when long/double parameters are present

Liam Miller-Cushon cushon at google.com
Fri Dec 2 16:41:32 UTC 2016


Thanks Jan, I've attached the full patch with a test.

On Fri, Dec 2, 2016 at 5:31 AM, Jan Lahoda <jan.lahoda at oracle.com> wrote:

> Hi Liam,
>
> Thanks for the report and patch, I've filled:
> https://bugs.openjdk.java.net/browse/JDK-8170667
>
> I think you are right about the problem, and the fix seems very reasonable
> to me.
>
> Jan
>
>
> On 2.12.2016 03:09, Liam Miller-Cushon wrote:
>
>> I think I found a MethodParameters class reading bug that affects
>> annotation processing.
>>
>> If MethodParameters attributes are not available parameter names are
>> inferred from the LVT, which uses two slots for doubles and longs. The
>> logic for skipping the extra slot is used even if the data was read from
>> a MethodParameters attribute, where the indices are always contiguous.
>> So if javac sees a parameter of type double or long it skips the next
>> entry in the MethodParameters table.
>>
>> There's a simple fix:
>>
>> diff -r 775a385c4af6
>> src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java
>> ---
>> a/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/
>> ClassReader.javaThu
>> Dec 01 17:25:45 2016 -0800
>> +++
>> b/src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/
>> ClassReader.javaThu
>> Dec 01 18:05:14 2016 -0800
>> @@ -2321,7 +2321,7 @@
>>                       ? parameterNameIndices[index] : 0);
>>               Name name = nameIdx == 0 ? names.empty : readName(nameIdx);
>>               paramNames = paramNames.prepend(name);
>> -            index += Code.width(t);
>> +            index += sawMethodParameters ? 1 : Code.width(t);
>>           }
>>           sym.savedParameterNames = paramNames.reverse();
>>       }
>>
>> If my diagnosis sounds correct, I can clean up the patch and add a test.
>>
>> Here's the full repro:
>>
>> === Lib.java
>> class Lib {
>>    void f(int a, long b, int c, int d) {}
>> }
>> === Test.java
>> @Deprecated
>> class Test {}
>> === ParameterProcessor.java
>> import java.util.Set;
>> import javax.annotation.processing.*;
>> import javax.lang.model.SourceVersion;
>> import javax.lang.model.element.*;
>>
>> @SupportedAnnotationTypes("*")
>> public class ParameterProcessor extends AbstractProcessor {
>>    @Override
>>    public boolean process(Set<? extends TypeElement> annotations,
>> RoundEnvironment roundEnv) {
>>      if (roundEnv.processingOver()) {
>>        return false;
>>      }
>>      TypeElement s = processingEnv.getElementUtils(
>> ).getTypeElement("Lib");
>>      for (Element e : s.getEnclosedElements()) {
>>        if (e instanceof ExecutableElement) {
>>          for (VariableElement v : ((ExecutableElement)
>> e).getParameters()) {
>>            System.err.printf("  %s %s\n", v.asType(), v.getSimpleName());
>>          }
>>        }
>>      }
>>      return false;
>>    }
>>
>>    @Override
>>    public SourceVersion getSupportedSourceVersion() {
>>      return SourceVersion.latest();
>>    }
>> }
>>
>> $ javac -parameters Lib.java
>> $ javac ParameterProcessor.java
>> $ javac -processor ParameterProcessor Test.java
>>    int a
>>    long b
>>    int d
>>    int arg3
>>
>> Note that the third parameter is given the fourth parameter's name, and
>> the fourth parameter's name is unknown.
>>
>> Thanks,
>>
>> Liam
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161202/3b5797b4/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 8170667.patch
Type: application/octet-stream
Size: 11092 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20161202/3b5797b4/8170667-0001.patch>


More information about the compiler-dev mailing list