Update GDScript highlighting for Godot 4

[sockeye-d]

This removes export and related keywords from the list of keywords and adds a new rule for highlighting annotations

[Andriamanitra]

I would rather keep old keywords around because someone could be editing code written for an old Godot version.

[sockeye-d]

Finally got around to fixing this. I

• added back the Godot 3 keywords
• added the rest of Godot 4's Variant types
• replaced the built-in node name highlighting with a more generic one that just highlights all words that start with an uppercase letter
• Added a new highlighting rule for CONSTANT_CASE constants

[Andriamanitra]

I tested with two GDScript files I found on Github:

• syntax_test_gdscript.gd
• long.gd

Triple quoted strings are missing handling for escaped characters, and I think it would make sense to make triple quoted strings into strings rather than comments (the documentation no longer mentions triple quoted strings as a way to create comments).

Other than that everything seems to look good.

[Andriamanitra]

The triple quoted string highlighting actually needs to be above single quoted strings or the highlighting will see """x""" as three single quoted strings rather than one triple quoted string. ¹ Check with syntax_test_gdscript.gd (it's easier to see what's going on while testing if you temporarily make triple quoted strings different color). You probably also need skip: "\\\\." to pass this test case:

var x = """ \""" """
var y = 123

Footnotes

1. confusingly this is different than the situation we had earlier where the later rule was being applied on top of an earlier rule, that won't happen with groups with start/end. ↩

[sockeye-d]

I think this should fix that?

[JoeKar]

Can a function start with a number?
I assume that it is intentional to highlight the opening bracket, but not the closing, right?

[Andriamanitra]

The bracket gets its color from statement later anyway so it doesn't matter. It's there just to limit the highlighting to function calls.

[sockeye-d]

Yep, the opening bracket just gets rehighlighted elsewhere. I couldn't figure out how to get a lookahead working so that was my next best option. I've fixed the function highlighting to check for word boundaries and handle numbers properly

[JoeKar]

But that is not more than an unintended hack.
This should stop working after the highlighter is reworked, in which it builds kind of a tree.
Unless we improve the skip in that way in which it really was intended to work (provide a sort of a look ahead/around).

BTW:
Missed this one - identifier: "func\\s+[a-zA-Z_0-9]+"?

[Andriamanitra]

But that is not more than an unintended hack.
This should stop working after the highlighter is reworked, in which it builds kind of a tree.
Unless we improve the skip in that way in which it really was intended to work (provide a sort of a look ahead/around).

I'm pretty sure it's an intended hack. It is already in use in other syntaxes ¹, some of which have been using it ever since the current highlighting system was introduced in 2fcb40d.

Footnotes

1. Grepping for \\(" found kvlang, Lua, and PHP, and I'm pretty sure there are others that use the same trick for something slightly different ↩

[JoeKar]

Well, okay...doesn't make the intended rework easier, when rules are intended to overlap. 🤔
Dirty thing...

[JoeKar]

Not * as in line 21 with [a-zA-Z_][a-zA-Z_0-9]*?
It should follow the same rule for the function name, at least I'd expect.