fix(builtin/type): a plain array never matches a map type

[mck]

Part of #142 (item 7).

What

matchesMapType and typeAssert's inline map-type branch accepted any
non-null object as a candidate map, including a plain JS Array.

Why

Object.entries() of an array yields string-indexed pairs
([['0', v0], ['1', v1], ...]), which pass the key/elem sampling used to
structurally match a map type. So a Go type switch that lists
case map[string]any: before case []any: captures slices in the map
branch, and ranging over the result calls Array.prototype.entries(),
producing numeric-keyed output instead of correct slice semantics:

var v any = []any{"a", "b"}
switch x := v.(type) {
case map[string]any:
    // wrongly taken; x behaves like {0: "a", 1: "b"}
case []any:
    // never reached
}

A Go slice is never a map, so both matchesMapType and typeAssert's map
branch now reject Array/Uint8Array values up front before doing any
key/elem sampling — no further type information is needed to know a slice
isn't a map.

Fix

Two mechanical guards, added right after the existing null/object checks:

• matchesMapType: if (Array.isArray(value) || value instanceof Uint8Array) return false
• typeAssert's inline map branch: same condition added to the guard so it
  falls through to the normal matchesType path (which now correctly
  rejects it via the fixed matchesMapType) instead of the special-cased
  map-assertion logic.

Test

Added gs/builtin/type.test.ts covering is(), typeAssert(), and
typeSwitch() against map[string]any vs []any, plus the empty-value
edge case: an empty map[string]any check previously matched an empty
array too, via the "empty map matches any map type" shortcut in both
functions.

All cases fail on master and pass with this fix.

Verify

bun run vitest run gs/builtin/type.test.ts

7 passed.

Full suite:

• bun run typecheck — clean
• bun run test:js (typecheck + vitest) — 1278 passed, 4 skipped, 0 failed
• go test ./... — all packages green
• bun run lint:js — clean

Found while transpiling and running a real ~100k-LOC Go interpreter/parser
package through goscript.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

This PR fixes a correctness bug in GoScript’s runtime type system where JavaScript arrays (and Uint8Array byte-slice values) could be structurally misclassified as Go map types during is()/typeAssert()/typeSwitch() evaluation, causing type switches to take the wrong branch.

Changes:

• Add an early guard in matchesMapType() to reject Array and Uint8Array candidates before map key/elem sampling.
• Add the same guard to typeAssert()’s inline map-assertion fast path so arrays fall through to the normal matchesType() logic.
• Add Vitest coverage to ensure slices don’t match map[string]any and that typeSwitch() selects the slice case.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 2 comments.

File	Description
gs/builtin/type.ts	Prevents arrays/byte-slices from being treated as map candidates during structural map matching and map assertions.
gs/builtin/type.test.ts	Adds regression tests for array-vs-map matching across is(), typeAssert(), and typeSwitch().

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[mck]

Good catch — added a Uint8Array case alongside the plain-array is()/typeAssert() rejection tests in 15b6345.

[mck]

Good catch — added an explicit empty-Uint8Array assertion to the empty-map-fast-path test in 15b6345.

[paralin]

Looks good. I verified the current head is still 15b63454, including the extra Uint8Array coverage added after Copilot's comments.

Rejecting Array and Uint8Array before the map structural matcher is the right fix: a Go slice or byte slice is never a map, so the runtime can reject those shapes before key/element sampling.

Focused check:

bun run vitest run gs/builtin/type.test.ts
# 7 passed