Incorrect handling of generic function calls

[IlyasYOY]

I found a problem in parsing code like this:

package main

func test[T any](t T) *T {
	return &t
}

func main() {
	val := test[int](123)
}

I get test[int](a) recognised as a type cast not as a function call.

Here are some tree-sitter tests patch:

diff --git a/test/corpus/expressions.txt b/test/corpus/expressions.txt
index 1b86acf..fd49e71 100644
--- a/test/corpus/expressions.txt
+++ b/test/corpus/expressions.txt
@@ -485,3 +485,104 @@ func main() {
               (call_expression
                 (identifier)
                 (argument_list)))))))))
+
+================================================================================
+Call function with generic parameter
+================================================================================
+
+package main
+
+func test[T any](t T) *T {
+	return &t
+}
+
+func main() {
+	val := test[int](123)
+}
+
+--------------------------------------------------------------------------------
+
+(source_file
+  (package_clause
+    (package_identifier))
+  (function_declaration
+    name: (identifier)
+    type_parameters: (type_parameter_list
+      (type_parameter_declaration
+        name: (identifier)
+        type: (type_constraint
+          (type_identifier))))
+    parameters: (parameter_list
+      (parameter_declaration
+        name: (identifier)
+        type: (type_identifier)))
+    result: (pointer_type
+      (type_identifier))
+    body: (block
+      (statement_list
+        (return_statement
+          (expression_list
+            (unary_expression
+              operand: (identifier)))))))
+  (function_declaration
+    name: (identifier)
+    parameters: (parameter_list)
+    body: (block
+      (statement_list
+        (short_var_declaration
+          left: (expression_list
+            (identifier))
+          right: (expression_list
+            (type_conversion_expression
+              type: (generic_type
+                type: (type_identifier)
+                type_arguments: (type_arguments
+                  (type_elem
+                    (type_identifier))))
+              operand: (int_literal))))))))
+
+================================================================================
+Call function without generic parameter
+================================================================================
+
+package main
+
+func test(t any) any {
+	return &t
+}
+
+func main() {
+	val := test(123)
+}
+
+--------------------------------------------------------------------------------
+
+(source_file
+  (package_clause
+    (package_identifier))
+  (function_declaration
+    name: (identifier)
+    parameters: (parameter_list
+      (parameter_declaration
+        name: (identifier)
+        type: (type_identifier)))
+    result: (type_identifier)
+    body: (block
+      (statement_list
+        (return_statement
+          (expression_list
+            (unary_expression
+              operand: (identifier)))))))
+  (function_declaration
+    name: (identifier)
+    parameters: (parameter_list)
+    body: (block
+      (statement_list
+        (short_var_declaration
+          left: (expression_list
+            (identifier))
+          right: (expression_list
+            (call_expression
+              function: (identifier)
+              arguments: (argument_list
+                (int_literal)))))))))

Both tests pass and the first one shows that expression is not recognized correctly: type_conversion_expression.

Here is the snippet from go doc:

When using a generic function, type arguments may be provided explicitly, or they may be partially or completely inferred from the context in which the function is used. Provided that they can be inferred, type argument lists may be omitted entirely

---

I found issue during neovim usage. Function wasn't colored correctly.

[IlyasYOY]

@amaanq Hello! AFAIU you are the active contributor now, so I'm tagging you here.

What do you think? May I try to provide a PR? I'd be really pleased to do so.

Maybe there are obvious reasons it cannot be implemented, or any other thoughts?

[IlyasYOY]

I tried to do something with this but I got problems. AFAIU there is a conflict between call_expression and type_conversion_expression.

I looked up go source code:

• https://github.com/golang/go/blob/f2cd93aa0505465c1d30201c806b6d4d3481c5fa/src/go/parser/parser.go#L1640-L1664
• https://github.com/golang/go/blob/5a9ad8b9e3a5835c3dc051fff97c1d81844260f6/src/pkg/go/parser/parser.go#L1097

Looks the type conversion is the same call expressions for their use-case.

I'm far not an expert in parsers but I guess we won't be able to distinguish this two cases. 🤔 Seems like we need info on types/functions to do so.

UPD. for code like this:

package main

import "fmt"

func test[T any](t T) *T {
	return &t
}

type some int

func main() {
	val := some(123)
	fmt.Println(val)
}

I get AST like this:

   178  .  .  .  .  .  .  Rhs: []ast.Expr (len = 1) {
   179  .  .  .  .  .  .  .  0: *ast.CallExpr {
   180  .  .  .  .  .  .  .  .  Fun: *ast.Ident {
   181  .  .  .  .  .  .  .  .  .  NamePos: 12:9
   182  .  .  .  .  .  .  .  .  .  Name: "some"
   183  .  .  .  .  .  .  .  .  .  Obj: *(obj @ 129)
   184  .  .  .  .  .  .  .  .  }
   185  .  .  .  .  .  .  .  .  Lparen: 12:13
   186  .  .  .  .  .  .  .  .  Args: []ast.Expr (len = 1) {
   187  .  .  .  .  .  .  .  .  .  0: *ast.BasicLit {
   188  .  .  .  .  .  .  .  .  .  .  ValuePos: 12:14
   189  .  .  .  .  .  .  .  .  .  .  Kind: INT
   190  .  .  .  .  .  .  .  .  .  .  Value: "123"
   191  .  .  .  .  .  .  .  .  .  }
   192  .  .  .  .  .  .  .  .  }
   193  .  .  .  .  .  .  .  .  Ellipsis: -
   194  .  .  .  .  .  .  .  .  Rparen: 12:17
   195  .  .  .  .  .  .  .  }
   196  .  .  .  .  .  .  }
   197  .  .  .  .  .  }

And in neovim I get some as function call, not as conversion:

• @function.call.go links to Special priority: 100 language: go

[IlyasYOY]

After thinking about it more, I think the parser probably should not try to classify ambiguous named forms as type_conversion_expression.

At the syntax-only parser level, these are not distinguishable without semantic/type information:

T(x)        // call if T is a function, conversion if T is a type
T[int](x)   // call if T is a generic function, conversion if T is a generic type
pkg.T(x)    // same ambiguity
pkg.T[int](x)

So maybe a saner default for tree-sitter-go would be:

• parse conversions only when the grammar has strong syntactic evidence that the callee is a type;
• keep builtin/predeclared types like int(x), string(x), float64(x) as type_conversion_expression;
• keep syntactically explicit types like []byte(x), map[string]int(x), struct{...}(x), (*T)(x) as type_conversion_expression;
• parse ambiguous identifier / selector / generic forms like T(x), pkg.T(x), T[int](x), pkg.T[int](x) as call_expression.

This would be better for highlighting because function calls are much more common in ambiguous expression-looking positions, and semantic tools can still reinterpret the node later if they have type information.

I realize this may be a breaking parse-tree change for named conversions such as:

UserID(raw)
MyString(s)

But those are exactly the cases where a syntax-only parser cannot actually know whether the name is a type or a function. So it seems better to avoid calling them conversions unless the syntax gives us stronger evidence.