[Kernel] VariableDeclaration should have more properties to help clients

[rakudrama]

It would be helpful if VariableDeclaration had more properties to capture common questions from the client.

What is it?

• Is the variable a user-defined variable or a synthesized variable
  • Needed for improved debugging experience
  • Useful for prioritizing 'nice' names in non-minified code
• Is the variable a parameter?
  • VariableDeclaration has properties that pertain only to parameters. Could VariableDeclaration and (new) ParameterDeclaration be subclasses of a common class?

How is it used?

The following summary properties would be useful to transformers and back-ends.
These properties would be much more useful if updated automatically when a transform changes the usage.

• Most parameters and many variables are single-definition-multiple-use even if not declared final.
• Some variables are closed-over by local functions or closures. Which variables have dynamic extent due to this?

/cc @fishythefish @annagrin

[johnniwinther]

cc @alexmarkov @nshahan

[alexmarkov]

VM also needs a way to distinguish synthetic variables in order to hide them in the debugger (#51512).

I see the following ways of doing that:

1. Remove names from all synthetic variables. Currently, front-end sometimes generates synthetic variables without names, and VM recognizes those and hides them. We can probably do that for all synthetic variables. The disadvantage of this approach is that we would not be able to give more readable names for those synthetic variables, which can be useful when examining kernel. Also, I heard that at some point VM needed a variable name if variable is captured. This limitation should be fixed if it still exists and we take this approach.

2. Adopt a fixed and unified naming scheme for synthetic variables. For example, we can make sure that names of synthetic variables always start with #. Front-end could provide helper functions to generate such names and use them uniformly. VariableDeclaration.isSynthetic predicate can be implemented by looking at the name, and VM can be also modified to recognize names starting with #. The advantage of this approach is that we would be able to give readable names to synthetic variables, but this may need a thorough sweep over front-end to make sure helper functions for generating synthetic names are used everywhere.

3. Add isSynthetic flag to VariableDeclaration. This is probably the most flexible approach, but probably more complex, as we would need to propagate this flag in the front-end, kernel and in the VM from kernel through compiler to the debugger. Variable names are already passed so solutions based on names don't need this extra handling.

[annagrin]

DDC needs this as well of course. We need to identify variables that are generated by the CFE and do not need to be shown in the debugger. Either adding a kind to the VariableDeclaration or marking it as synthetic will work for us.

Here is an example of what currently shows in the debugger on web platform for patterns: dart-lang/webdev#1974

/cc @nshahan @Markzipan

[annagrin]

Thanks @johnniwinther! I am able to replace CFE-synthesized names by temporaries now and most of them now don't show in the debugger.

There is one case that still looks code-unrelated, an I think is related to constant propagation changing names in cases in

sdk/pkg/front_end/lib/src/fasta/kernel/constant_evaluator.dart

Line 1126 in 9703692

variables[i].name = '${variables[i].name}${"#$i"}';

Those replaced names are not marked as synthesized and show in the debugger without real connection to the code:

It looks like the new names are replacing a and n in the second case:

[itsjustkevin]

@johnniwinther is there work left to be completed here?

[johnniwinther]

Moved to post release.