RFR: JEP 359-Records: compiler code

[Jan Lahoda]

Not sure if the compact constructor should be modeled as a block - the 
constructors may have annotations, the explicit statements may contain 
references to the parameters, etc.

One possibility might be to have the MethodTree.getParameters() return 
null ("missing in the source code"). Or, the injected parameters, when 
entered, could be marked MANDATED, which may be as easy as:

diff -r ad4a9419b8e0 
src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java
--- 
a/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java 
        Thu Oct 31 00:41:57 2019 -0400
+++ 
b/src/jdk.compiler/share/classes/com/sun/tools/javac/parser/JavacParser.java 
        Thu Oct 31 18:05:23 2019 +0100
@@ -3746,7 +3746,7 @@
                      ListBuffer<JCVariableDecl> tmpParams = new 
ListBuffer<>();
                      for (JCVariableDecl param : headerFields) {
                          tmpParams.add(F.at(param)
-                                .VarDef(F.Modifiers(Flags.PARAMETER | 
param.mods.flags & Flags.VARARGS | param.mods.flags & Flags.FINAL),
+                                .VarDef(F.Modifiers(Flags.PARAMETER | 
Flags.MANDATED | param.mods.flags & Flags.VARARGS | param.mods.flags & 
Flags.FINAL),
                                  param.name, param.vartype, null));
                      }
                      methDef.params = tmpParams.toList();

Jan

On 31. 10. 19 15:03, Maurizio Cimadamore wrote:
> The idea sounds good, in the sense that a compact record constructor is 
> more similar to an initializer block than it is to a regular 
> constructor, so I can see it being modeled as a JCBlock with the RECORD 
> flag set. This is also made easier by the fact that we no longer allow 
> instance initializers on records (**).
> 
> That said, if the compact constructor becomes a block, I'm pretty sure 
> we'll run into issues with respect to source reflection - blocks are 
> typically looked at in Attr, which is too late for source 
> reflection/annotation processing. So I agree that, while it looks like a 
> promising direction, it will probably be a non-trivial effort, and it 
> would better be postponed as a followup cleanup
> 
> Maurizio
> 
> (*) In the list of error messages in [1] I don't see anything about 
> 'illegal instance initializer in record declaration' - is that an 
> omission in the diagnostic examples, or a more serious issue in the 
> code/spec?
> 
> [1] - 
> http://cr.openjdk.java.net/~vromero/records.review/compiler/webrev.02/
> 
> On 31/10/2019 13:22, Vicente Romero wrote:
>> Hi Srikanth,
>>
>> On 10/30/19 11:41 PM, Srikanth wrote:
>>>
>>>
>>> On 30/10/19 11:37 PM, Vicente Romero wrote:
>>>> (12) Compact constructor trees are modified in in 
>>>> com.sun.tools.javac.parser.JavacParser#recordDeclaration to become 
>>>> elaborated tree - I thought this practice of modifying parse trees 
>>>> in the early stages is frowned upon ?? (Other parse tree 
>>>> transformations also happen here)
>>>>
>>>> right but no other feature allows to declare a parameter-less 
>>>> method. If not expanded here the compact constructor would have to 
>>>> be expanded in TypeEnter, which probably is not very nice either, so 
>>>> I didn't see a perfect solution
>>>
>>> It may be quite a bit of work, but the canonical solution would be to 
>>> introduce a new node type to model these. Not asking it to be done. 
>>> Just saying.
>>
>> yep, what you are saying sounds good, we could revisit this later on
>>>
>>> Srikanth
>>>
>> Thanks,
>> Vicente