👋 I maintain the built in grammars in VS Code. The Go grammar we're currently using hasn't been updated in a while, and I see that the grammar in https://github.com/worlpaker/go-syntax/blob/master/syntaxes/go.tmLanguage.json solves some known issues and generally highlights Go well.

I'm planning to try out https://github.com/worlpaker/go-syntax/blob/master/syntaxes/go.tmLanguage.json as the default Go grammar in VS Code Insiders for month or two. If I don't hear much negative feedback from the community, I'd like to use the grammar in VS Code stable.

@worlpaker, do you plan to maintain this grammar long term?

"patterns" does not work when "match" is present
currently it doesn't do anything and can be removed

also the brackets in "match" can be removed \\w+

if you want to retokenize ([\\s\\,\\w]+) with \\w+
you need to place "match" inside a "patterns": [] array
(or just add an empty "patterns" array, but that is not recommended)

Hello! I noticed that 2d-slices are not highlighting, when it is field of structure. for example:

package main

type cell struct{}

type board struct {
	matrixCells        [][]cell
	matrixCellsPointer *[][]cell
	rowCells           []cell
	rowCellsPointer    *[]cell

	matrixInts        [][]int
	matrixIntsPointer *[][]int
}

func main() {
	test := new(board)
}

Monokai theme

Interestingly, if you assign a pointer to a 2d slice, the highlighting works

This problem also appears with as many-dimensional sliсes as with arrays.

Expected different color of struct variable name and field:

type AppConfig struct {
	Brand              string         `json:"brand"`
	BundleID           string         `json:"bundleId"`
	AppName            string         `json:"appName"`
	Skin               string         `json:"skin"`
} 
var config AppConfig

	appConfig := AppConfig{
		Brand:              config.Brand,
		BundleID:           config.BundleID,
		AppName:            settings.AppName,
		Skin:               settings.Skin,
}

Behavior:

Current behavior looks unreadble, is it possible to switch colors.

VSCode 1.88.0 colors this function incorrectly:

All the argument names should be the same color, like gopls with semantic tokens enabled does it:

VSCode colors the following incorrectly:

var (
	vertexData = gblob.LittleEndianBlock(make([]byte, len(geometry.vertices)*int(stride)))
)

if 5 > 10 {

}

The if keyword is light blue instead of the standard purple.

This is a redirect of an issue opened originally to gopls. Please check issue for more detailed information if needed:
golang/vscode-go#3370

Steps to replicate:

Copy paste this on top of a go file.
var demo = regexp.MustCompile(^(?i)(CS)(\d{3,4}))

On go 1.21.0
All extensions disabled.
VS code about.

Version: 1.86.0 (Universal)
Commit: 05047486b6df5eb8d44b2ecd70ea3bdf775fd937
Date: 2024-01-31T10:29:15.765Z
Electron: 27.2.3
ElectronBuildId: 26495564
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Darwin x64 22.6.0

Hi, I found an inconsistency in syntax highlighting when incrementing and decrementing variables in loops. If in the third part of a for-loop we decrement a variable, the -- signs are blue instead of white. Below you can find an example of this behavior:

package main

func main() {
    for i := 0; i < 10; i++ {
        // Stuff
    }

    for i := 0; i < 10; i-- {
        // Stuff
    }

    i++
    i--
}

I'm open to working with you to fix this issue, let me know if there's anything I can help you with.

Problem

When naming a structure method with the same name as a type name, the method is highlighted as a type name when it is called. While it is not necessarily bad practice to give a method the same name as a type, this can lead to confusion and reduced code readability.

Illustrating problem

type Test struct{}

func (t Test) Testing() error {
	t.normalName()
	t.error()
	t.int()
	t.any()

	return nil
}

func (t Test) normalName() {}

func (t Test) error() {}

func (t Test) int() {}

func (t Test) any() {}

Using the Ayu Mirage theme, all function calls should be the same color as t.normalName().

Motivation

The proposed change aims to improve code readability and clarity by ensuring that method calls with the same name as a type are highlighted as normal function calls, rather than as type names.

Reason

In the go.tmLanguage.json file, a regular expression is used to identify the type names in the code. For example, this is the pattern for the error type:

"storage_types": {
	"patterns": [
		{
			"match": "\\berror\\b",
			"name": "storage.type.error.go"
		}
	]
}

However, this pattern fails to distinguish between method calls and type names when they share the same name. As a result, method calls with the same name as a type are highlighted as type names.

Possible solution

One possible solution is to modify the regular expression in the storage_types section of go.tmLanguage.json to check for a dot (.) preceding the type name. This would ensure that the regular expression only matches type names that are not part of a method call. Here's an example of how this could be done for the error type:

"storage_types": {
	"patterns": [
		{
			"match": "(?<!\\.)\\berror\\b",
			"name": "storage.type.error.go"
		}
	]
}

By adding (?<!\\.) before the type name, the regular expression ensures that the type name is not preceded by a dot, which indicates that it is part of a method call.

This solution can be applied to all type names in go.tmLanguage.json to ensure that method calls with the same name as a type are highlighted as normal function calls.