syntax: highlight the Go predeclared identifiers added since 1.18

[yu2971512385-ui]

runtime/syntax/go.yaml lists Go's predeclared identifiers, but five of them are missing, so they stay unhighlighted while their neighbours in the same rules are highlighted:

identifier	added in	today	with this change
any	1.18	(unhighlighted)	type, like error
comparable	1.18	(unhighlighted)	type
clear, min, max	1.21	(unhighlighted)	preproc, like len

Checked with micro's own highlighter (pkg/highlight):

before: "var payload any = 1"  ->  0:preproc 16:symbol.operator 18:constant.number
after : "var payload any = 1"  ->  0:preproc 12:type 16:symbol.operator 18:constant.number

before: "clear(m)"             ->  5:symbol.brackets
after : "clear(m)"             ->  0:preproc 5:symbol.brackets

error, len and everything else are unaffected: the two types join the existing type rule, the three functions the existing preproc rule that already holds make, new, copy, len, cap and the rest.

AI assistance (Claude) was used to find this — by running language snippets through highlighters and flagging what comes back unstyled — and to draft this description. I verified the before/after with micro's highlighter myself.

🤖 Generated with Claude Code

[Andriamanitra]

Nice addition.

I noticed that the built-in functions complex, real, and imag are also missing from the syntax.

It's also pretty weird that println is special but print is preproc (since #1455). I would rather highlight builtin functions as identifier, but maybe we shouldn't mess with it more than we need to if users have already gotten used to this "wrong" highlighting in Go...

[yu2971512385-ui]

Good catch — complex, real and imag were missing too. Added them to the same preproc rule; checked with micro's highlighter that they now match and that a word merely starting with one does not:

"c := complex(1, 2)"  -> 5:preproc
"r := real(c)"        -> 5:preproc
"i := imag(c)"        -> 5:preproc
"var complexity = 1"  -> (unhighlighted, as before)

That makes the rule complete against the spec's predeclared functions, with println being the odd one out in special.

On println vs print: I agree the split is hard to defend, and identifier for all builtins would be the tidier model. I left it alone deliberately — it changes how existing Go files look for everyone, which feels like its own change with its own discussion rather than something to slip into a keyword addition. Happy to send that as a separate PR if you want it, either moving println down to preproc for consistency or moving the whole set to identifier; just say which way you'd prefer.

[Andriamanitra]

Let's just move println to preproc for consistency. The highlighting has been like this for a good while already and users don't seem to mind. The builtins can always be moved to a different group in a separate PR at a later date.