Fwd: Mandated/implicit parameters

[Hannes Greule]

I finally found some time to come back to this.

I applied changes to also include the attribute if synthetic parameters 
are present. I only have tests for the mandated flag for now, as I don't 
know all the cases where synthetic parameters are emitted (and as that 
might change at any time, such tests would be hard to maintain probably).

I also wrote a test for annotated parameter types in core reflection, 
however it seems like my code does not fix it in the case of enum ctors. 
Therefore I did not include it, as I think that should be addressed 
separately.

The ClassReader now also works with unnamed parameters in the 
MethodParameter attribute, and reads from the LVT instead if present.

I submitted a report on https://bugs.java.com/ and awaiting response 
there. Once it's added to the bug tracker, I'll open a PR as I think my 
changes are ready for review.

Greetings
Hannes

On 09.06.2022 18:09, Hannes Greule wrote:
>  > Your patch looks nice. I suggest, in addition, to write the attribute
>  > when any synthetic parameter is present as well (such as the first two
>  > String and int of enum constructors).
> 
> Thank you. I'll look into synthetic parameters too.
> 
>  > In addition, I would recommend a
>  > test for core reflection to ensure the newly emitted attributes allow
>  > core reflection to correctly describe the parameterized types of inner
>  > class constructors, etc.
> 
> I think I also need a test for the compiler output. I'll start working 
> on that.
> 
>  > Once you can find a related issue on the bug tracker (or report one at
>  > https://bugs.java.com/ if you can't find a fitting one), you can
>  > submit this patch for that bug tracker issue.
> 
> I found JDK-8213329: Normalize inclusion of non-explicit parameters in 
> JVM attributes[1] but that doesn't really fit the issue. I'll report a 
> new one.
> 
>  > For the ClassReader, I think you may need a `index++;` before the
>  > `continue;`, as that would better match the behavior of
>  > LocalVariableTable register-based index assigning.
> 
> I looked into that a bit more. It seems more complicated as the 
> ClassReader reads names from both the LocalVariableTable and the 
> MethodParameters attribute if both are present. However, if the 
> MethodParameters attribute is read after the LocalVariableTable, it will 
> replace names from the LocalVariableTable. This causes issues if no 
> names are written to the MethodParameters attribute.
> I'm not sure what the best approach would be here, especially as 
> indexing is different (due to the slot for `this` in non-static 
> methods/ctors).
> 
> [1] https://bugs.openjdk.org/browse/JDK-8213329