lezer-parser/java

Java grammar for Lezer

java's Issues

Identifiers parsed as error when starting with upper case letters

I ran into this issue when working with labels starting with upper case letters. By the specification, this is valid. The grammar defines identifiers as starting with only lower case letters.

Java program

This program is accepted by the java compiler.

package tests;

@Deprecated(since = "9")
public class Simple {
	private static final String HELLO = "Hello, world!";

	public static void main(String[] args) {
		System.out.println(HELLO);
		Label: for (int i = 0; i < 5; i++) {
			if (i == 2)
				break Label;
		}
	}
}

Lezer Tree for `main`

MethodDeclaration(
	Modifiers(public,static),
	void,
	Definition,
	FormalParameters(
		"(",
		FormalParameter(
			ArrayType(TypeName,Dimension("[","]")),
			Definition
		),
		")"
	),
	Block(
		"{",
		ExpressionStatement(
			MethodInvocation(
				FieldAccess(Identifier,".",Identifier),
				".",
				MethodName(Identifier),
				ArgumentList("(",Identifier,")")
			),
			";"
		),
		ExpressionStatement(Identifier,⚠(":")),
		ForStatement(
			for,
			ForSpec(
				"(",
				LocalVariableDeclaration(
					PrimitiveType,
					VariableDeclarator(Definition,AssignOp,IntegerLiteral),
					";"
				),
				BinaryExpression(Identifier,CompareOp,IntegerLiteral),
				";",
				UpdateExpression(Identifier,UpdateOp),
				")"
			),
			Block(
				"{",
				IfStatement(if,
					ParenthesizedExpression(
						"(",
						BinaryExpression(Identifier,CompareOp,IntegerLiteral),
						")"
					),
					BreakStatement(break,⚠)
				),
				ExpressionStatement(Identifier,";"),
				"}"
			)
		),
		"}"
	)
)

'\\n'; or more backslash match to ExpressionStatement(CharacterLiteral)

JDK compile failed because of too many characters in character literal

Why are unmatched array dimensions valid?

I am working on a tree traversal library for lezer/java and found this definition which was a bit strange for me:

Dimension {
  annotation* !array "[" "]"+
}

This leads me to my question: Why is int[]] a valid syntax in this grammar? Is this intended?

Here's a valid syntax tree parsed by this grammar:

class HelloWorld {
    public static void main(String[]] args) {
        System.out.println("Hello, World!");
    }
}

Program:
└╴ClassDeclaration:
  ├╴class
  ├╴Definition: HelloWorld
  └╴ClassBody:
    ├╴{
    ├╴MethodDeclaration:
    │ ├╴Modifiers:
    │ │ ├╴public
    │ │ └╴static
    │ ├╴void
    │ ├╴Definition: main
    │ ├╴FormalParameters:
    │ │ ├╴(
    │ │ ├╴FormalParameter:
    │ │ │ ├╴ArrayType:
    │ │ │ │ ├╴TypeName: String
    │ │ │ │ └╴Dimension:
    │ │ │ │   ├╴[
    │ │ │ │   ├╴]
    │ │ │ │   └╴]
    │ │ │ └╴Definition: args
    │ │ └╴)
    │ └╴Block:
    │   ├╴{
    │   ├╴ExpressionStatement:
    │   │ ├╴MethodInvocation:
    │   │ │ ├╴FieldAccess:
    │   │ │ │ ├╴Identifier: System
    │   │ │ │ ├╴.
    │   │ │ │ └╴Identifier: out
    │   │ │ ├╴.
    │   │ │ ├╴MethodName:
    │   │ │ │ └╴Identifier: println
    │   │ │ └╴ArgumentList:
    │   │ │   ├╴(
    │   │ │   ├╴StringLiteral: "Hello, World!"
    │   │ │   └╴)
    │   │ └╴;
    │   └╴}
    └╴}

(Definition of "Dims" in the official Java 16 documentation)

precedence of operators reversed to treesitter

If you parse i < c + 1, you will get an AST that looks like this:

I'm expecting the CompareOp to have a lower precedence than the ArithOp. Looking at tree-sitter grammar, this is indeed the case, ADD has a higher precedence than REL.

In the grammar here, you will first notice that the order is reversed (which could have caused some confusion), and it looks like that compare now has a higher precedence than addition.

java/src/java.grammar

Lines 1 to 20 in d899688

	@precedence {
	cast
	update @left
	unaryPlus @left
	negate @left
	shift @left
	compare @left
	instanceof
	times @left
	plus @left
	and @left
	or @left
	ternary @right
	valuePair
	assign @right
	array @right
	new @right
	else @right
	scope @left
	typeArgs

Can somebody recheck the precedence here? Thank you!