two YAML files in github actions
testAndBuild.yml

on:
  push:
    branches: 
      - v*

testPR.yml :

on:
  pull_request:
    branches: 
      - v*

do we need both ?

• name is a String
• typeName is a FASTJavaTypeName

JavaSmaCCProgramNodeImporterVisitor seems to use typeName so I suggest to remove name
We could also change the importer to use name

We should check that we parse correctly this kind of expression

MyClass clzz = new SomeOtherClass(false, AnotherClass.this).new MyClass(args);

It looks like we only get one new expression instead of two

#expression contains the annotation class.
ex: in @Deprecated the expression is "Deprecated"

Currently this is typed as FASTJavaVariableExpression but:

• this is not an expression, it is a name "hard coded"
• it is not a variable but a class name

In an inner class one reference to the enclosing object with: EnclosingClass.this

Unless there is a specific reason not to use the trait, FASTJavaMethodInvocation should use FASTTInvocation.
This should replace the use of FASTTExpression and FASTTWithArguments.

There is currently no support for multidimensional arrays:

JavaSmaCCProgramNodeImporterVisitor new parseCodeString: 'class A{int[][] T;}'.

Inspecting the model shows a single instance of FASTJavaArrayTypeExpression with a baseType of FASTJavaIntTypeExpression, and the array's dimensions information has been lost.

I'm proposing a change to make such arrays nested.

It seems break; translates to a FASTJavaContinueStatement and that FASTJavaBreakStatement is not used

Not sure what the error is

When there is a blank line in the original source code separating 2 statements, it is not there in the exported code.

Seems difficult without creating special nodes (EmptyLine) in the AST which does not seem desirable.
May be we could use source anchors to compute this ?

When an array initializer specifies the size of each dimension :

And when it does not :

As you can see, when the size is specified, a FASTJavaIntegerLiteral is added to the arguments field of the node and therefore the information is kept after parsing.
However, if the size are not specified, there is no way (unless we infer it from the children nodes? doesn't sound like a good idea) to know how many dimensions this array has.

Most other array nodes (like accesses, or type expression) are built recursively in order to represent multi-dimensionality, so maybe the same logic could be applied for initializers?

var instanceof AClass comes out as varinstanceofAClass

Why not a FASTJavaTypeExpression ?

presumably:

• block comments (/* ... */) would be attached to the node just after their position in the AST
• line comments (// ...) would be attached to the node just before their position in the AST

visit method calls #expression

visitAnnotation: anAnnotation
	self create: FASTJavaAnnotation from: anAnnotation.
	currentFASTEntity expression: (self clone accept: anAnnotation name).

but anAnnotation name is not an expression

Currently there is no difference between two nodes a = 0; or a += 0;.
Maybe we should add an operator slot to keep that information in the node when parsing source code, or even have a different type of node for each type of assignment operator (feels a bit overkill in my opinion but that's an option).

For a CharacterLiteral 'A', the value should be just A, not 'A'

for (int i=0; i<10; i++)
	;

gives

int i = 0;
i++;
i<10

mooseName is not a name but a number ...

it is currently defined as FASTJavaVariableExpression which is twice wrong

• this is a Type, not a variable (see #39)
• this is not an expression but a FASTJavaTypeName

When using one or the other ?

Correct spelling is "assignment" and "assignable".

Catch statements only keep in memory the body, parameter and try owner.
However, as the parameter is a FASTJavaVariableExpression, it does not hold information on the type of the variable.

As catch statements can only have one variable, maybe simply adding a type slot (like FASTJavaVarDeclStatement for example) would do the trick.

seems similar to #64

for (AClass var : someCollection ) { ... }

currently is defined as FASTJavaClassTypeExpression

As you can see on the indicated nodes on the AST, modifiers are correctly added for class attributes, but it is not the case for the local variables of a method.

I made this example using this snippet of code :

JavaSmaCCProgramNodeImporterVisitor new parseCodeString: 
'
public class Test { 
	
	public final static String TEST_ATTRIBUTE = "bonjour";
	
	public void testMethod() { 
	
	final String testVariable = "au revoir";
	 
	} 
 
}
'

The problem was however first noticed through ASTs generated using real-world examples.

Currently, parsing

void method() throws MyException {
}

produces an AST without any information about throws MyException

public static final int FIELD = 5; comes out as int FIELD = 5;

I don't understand this inheritance ...

FASTJavaTypeExpression has #name and #typeName

#typeName points to a FASTJavaTypeName whereas #name points to a String
but #name is not used

In a visitor, always give priority to a visit from the children rather than a test.

In this case we could have:

FASTJavaExportVisitor >> visitFASTJavaUnaryExpression: aFASTJavaUnaryExpression
  aFASTJavaUnaryExpression isPrefixedUnaryExpression
    ifTrue: [ self visitFASTJavaPrefixedUnaryExpression: aFASTJavaUnaryExpression ]
    ifFalse: [ self visitFASTJavaPostfixedUnaryExpression: aFASTJavaUnaryExpression ]

and then trivially implement the 2 methods #visitFASTJavaPrefixedUnaryExpression and #visitFASTJavaPostfixedUnaryExpression.

The next step is to push up the implementation of FASTJavaExportVisitor>>visitFASTJavaUnaryExpression: into the abstract visitor.

-- @NicolasAnquetil regarding #23

ex: @Test(timeout=500)
the annotation will only keep the name: Test

mostly OK for blocks (statements inside blocks)
but when a if or a loop has only one instruction it is not indented
need to check also loop initialization and increment because they are "statements"

an expression 3+5 could be inside an expression 2*(3+5)
to make sure we regenerate the same code, we should put parentheses around all expressions

There is some incinsistency with trait usage.
For example FASTTModifier and FASTJavaWithModifiers

The expression ((AClass) obj.m1()).m2() comes out without parentheses (AClass) obj.m1().m2()