[yu2971512385-ui]

Issue #, if available: n/a

Description of changes:

golang_highlight_rules.js lists Go's predeclared identifiers as builtinTypes, but not the two the language gained in 1.18 with generics, so they are lexed as ordinary identifiers while error, string and the rest are types:

line	before	after
var x any	any → identifier	support.type
type S[E comparable] int	comparable → identifier	support.type

Tests: a new case in src/mode/golang_test.js asserts both, plus error as a control. It fails on master ('support.type' == 'identifier') and passes with the change; mocha "./src/mode/*_test.js" is green (81 passing, 1 pending).

Correction to the original version of this PR: it also added clear, max and min to builtinFunctions and claimed they were unstyled. That was wrong — the mode already scopes any identifier followed by ( as support.function, so those three are styled at every call site today. The only thing the addition changed was their appearance outside call position, where they are shadowable identifiers, so I removed that part and narrowed this to the two types.

Found by lexing modern-language snippets and flagging identifiers that stay unstyled. AI assistance (Claude) was used for that search and for drafting; I reviewed and tested every line, and the correction above came out of re-verifying the before/after behaviour against a pristine checkout.

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

Pull Request Checklist:

• No backwards incompatible changes were made to Ace's public interface
• Tests added/updated

🤖 Generated with Claude Code

Open kitchen-sink @ e690c632c99727a996d5d4965ea9cfc7ec23453b

[yu2971512385-ui]

Correction to my own PR: I narrowed it to any and comparable and dropped clear/max/min.

Re-checking against a pristine master showed those three are already scoped, because line 65 of the mode scopes any identifier followed by ( as support.function — foo(1) behaves the same way. Adding them to builtinFunctions only affected them outside call position (f := min), where they are shadowable identifiers, so the addition was not worth the regression risk. The before/after table in the description is updated accordingly.

Sorry for the noise; the two types are unaffected by that rule and remain a real gap.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.89%. Comparing base (62d5ffd) to head (e690c63).

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #6011      +/-   ##
==========================================
- Coverage   93.92%   93.89%   -0.03%     
==========================================
  Files         647      647              
  Lines      140792   140802      +10     
  Branches    14784    14758      -26     
==========================================
- Hits       132237   132206      -31     
- Misses       8555     8596      +41     

Flag	Coverage Δ
unittests	93.89% <100.00%> (-0.03%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[nightwing]

Thank you