Review request: update javac to properly output mandated parameters in MethodParameters attributes

[Eric McCorkle]

Okay this will indeed necessitate some modifications.

VarSymbols only seem to get created for the formal (explicitly declared)
parameters.  I had assumed (incorrectly, it seems) that SYNTHESIZED
parameters also got VarSymbols, and the extra parameters in externalType
represent MANDATED parameters.

It seems the thing to do is to mark all the extra parameters
SYNTHESIZED, *unless* they match certain cases, in which case they get
marked MANDATED.

If there is a better way to do this in javac, then please let me know.

On 02/07/13 17:06, Alex Buckley wrote:
> On 2/7/2013 12:29 PM, maurizio cimadamore wrote:
>> It would seem that the spec is not defining (on top of my head - there
>> are probably others):
>>
>> *) (effectively) final variables passed in to inner classes (javac only
>> does that for reference-types as others are just constants that can be
>> produced on the stack at will)
> 
> Right. The JLS does not say that those ctor parameters are implicitly
> declared. javac should mark them with ACC_SYNTHETIC.
> 
>> *) I believe javac's generated enum constructor has an additional
>> parameter accepting the ordinal
> 
> We need to be clear what we're talking abut here. For an enum type, JLS
> 8.9.2 has always implicitly declared a default ctor _with no formal
> parameters_ - but that ctor is required to be private, so no other
> compiler can emit code which uses it. I think you're talking not about
> the default ctor, but about an explicitly-declared ctor to which javac
> adds a parameter. In this case, is code from another compiler expected
> to use the parameter to construct the enum instance correctly? If yes,
> then the ordinal parameter should be implicitly declared. Please let me
> know so I can update the JLS.
> 
>> In any case, the implementation problem remains: it doesn't distinguish
>> between impl-only parameters and 'implicitly declared' ones. It just
>> takes all parameters that do not have a correspondent in the source code
>> and put them in the same place.
> 
> I hope Eric is out there somewhere :-)
> 
> Alex
-------------- next part --------------
A non-text attachment was scrubbed...
Name: eric_mccorkle.vcf
Type: text/x-vcard
Size: 314 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/compiler-dev/attachments/20130207/03ec6ab0/eric_mccorkle.vcf