[records] Mark generated toString/equals/hashCode in class files somehow?

[Alex Buckley]

You are right that ACC_MANDATED is not expressible for methods. This is 
unfortunate not only for equals/hashCode/toString in a record class, but 
also for values/valueOf in an enum class.

ACC_SYNTHETIC indicates an implementation artifact -- something that 
varies from compiler to compiler (or from one release of a compiler to 
the next release of the same compiler). It would be wrong to use 
ACC_SYNTHETIC to mark the five methods in the previous paragraph. They 
are language artifacts, whose existence + signature + semantics are the 
same across compilers.

It would be legitimate to add ACC_MANDATED to method_info.access_flags. 
ACC_MANDATED is defined as 0x8000 in other contexts, so convention 
dictates that it would have to be defined as 0x8000 in 
method_info.access_flags too. Happily, 0x8000 is available there. This 
also applies to field_info.access_flags.

Alex

On 8/6/2020 9:20 PM, Tagir Valeev wrote:
> Hello, Jonathan!
> 
> I believe, current JVM specification doesn't say that methods could be
> marked with ACC_MANDATED [1]. I won't mind if it will be used instead
> of SYNTHETIC. To me, anything is ok if I can avoid bytecode
> inspection.
> 
> With best regards,
> Tagir Valeev.
> 
> [1] https://docs.oracle.com/javase/specs/jvms/se14/html/jvms-4.html#jvms-4.6
> 
> On Fri, Aug 7, 2020 at 11:12 AM Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>>
>> Tagir,
>>
>> The concept and word you are looking for is "mandated", which is similar
>> to but different from "synthetic".
>>
>> See
>> https://docs.oracle.com/en/java/javase/14/docs/api/java.compiler/javax/lang/model/util/Elements.Origin.html#MANDATED
>>
>> -- Jon
>>
>>
>> On 8/6/20 8:48 PM, Tagir Valeev wrote:
>>> Hello!
>>>
>>> I'm working on class-file decompiler for records and discovered that
>>> there's no special flag for generated equals/hashCode/toString (like
>>> ACC_SYNTHETIC). This allows determining whether this method was
>>> explicitly specified in the source code only by looking into method
>>> implementation whether it has an ObjectMethods.bootstrap indy or not.
>>> This looks implementation-dependent and somewhat fragile (though, of
>>> course, we will do this if we have no other options). We also have a
>>> stub decompiler that decompiles declarations only without checking
>>> method bodies at all and it also wants to know whether
>>> equals/hashCode/toString methods were autogenerated. Finally, other
>>> bytecode tools like code coverage may need this to avoid calculating
>>> coverage for methods not present in the source.
>>>
>>> Is it possible to mark generated methods via ACC_SYNTHETIC or any
>>> other flag or add any attribute that can be used to differentiate
>>> auto-generated methods from the ones presented in the source code?
>>>
>>> Having a synthetic mark for auto-generated canonical constructor or
>>> accessor methods is less critical (as their bodies could be actually
>>> written in the source code like this) but it would be also nice to
>>> have it.
>>>
>>> With best regards,
>>> Tagir Valeev.