{"owner":"sebastienros","repo":"jint","hasSkills":true,"totalSkillsCount":2,"totalTokensCount":7771,"categories":["anthropic-skill","root-instruction"],"hasMcp":false,"mcpConfig":null,"found":[".claude/skills/test262-update/SKILL.md","AGENTS.md"],"skills":{".claude/skills/test262-update/SKILL.md":"---\nname: test262-update\ndescription: Bump Jint's pinned tc39/test262 SHA in Jint.Tests.Test262/Test262Harness.settings.json, triage the upstream commit range for normative changes, run the conformance suite, and fix whatever the new tests expose. Use when asked to update/upgrade test262, bump SuiteGitSha, pull in the latest conformance tests, or investigate a test262 conformance failure after a bump.\n---\n\n# Updating the pinned test262 suite\n\nThe visible change is one line — `SuiteGitSha` in `Jint.Tests.Test262/Test262Harness.settings.json`.\nTreat it as a **code** change anyway. Upstream lands tests for normative changes that Jint has not\nimplemented, and those turn green features red. The whole job is triaging the range before you run\nanything, then fixing the engine — never the tests.\n\n## Ground rules\n\n- **Never edit or \"fix\" a test262 test.** If a test is wrong, the answer is an engine fix or, as a last\n resort, an `ExcludedFiles` entry.\n- **test262 at the pinned SHA outranks the published prose.** See [Normative changes](#3-normative-changes--the-part-that-actually-costs-time).\n- Exclusions outside `intl402/` must be temporary and carry a comment naming what removes them. Today every\n `ExcludedFiles` entry is intl402 — keep that invariant.\n- A feature that arrives unimplemented parks in `ExcludedFeatures`; the PR that implements it removes the entry.\n- Work in a worktree, not the primary checkout, and start from a fresh `main`.\n\n## 0. Orient\n\n| Thing | Where |\n| --- | --- |\n| The pin | `Jint.Tests.Test262/Test262Harness.settings.json` → `SuiteGitSha` |\n| Local suite checkout (read-only aid) | `../test262` — `origin` = your fork, `upstream` = `tc39/test262` |\n| Generator | `dotnet test262 generate`, from `Jint.Tests.Test262/.config/dotnet-tools.json` |\n| Generated tests | `Jint.Tests.Test262/Generated/` — **gitignored**, so the committed diff stays one line |\n\nThe runner does **not** read `../test262`. `State.Test262StreamLoader` downloads the suite from GitHub at\n`SuiteGitSha`, so the local checkout exists only so you can read the range. Fetch it anyway — you cannot\ntriage without it.\n\nThe `GenerateTestSuite` MSBuild target hashes the settings file and the tool manifest into\n`Generated/.settings.hash`. Change any byte of either and the next build wipes `Generated/` and regenerates.\nSo: never pass `--no-build`, and if you suspect a stale generation, check the hash file rather than guessing.\n\n## 1. Establish the range\n\n```bash\ncd ../test262 && git fetch upstream\ngit log --oneline ..upstream/main # or .. if one was given\ngit diff ..upstream/main -- features.txt\ngit diff --name-only ..upstream/main | grep -v '^test/'\n```\n\n**Order commits by ancestry, never by author date.** test262 merges rebased branches, so a commit *authored*\nearlier routinely lands on top of one authored later — a real bump had `3655e746` (authored 08-03) sitting\nabove `be13516f` (authored 08-07). Use `--pretty='%h %cd %s'` or `git merge-base --is-ancestor` when the\nordering matters, and confirm the true remote tip with `git ls-remote https://github.com/tc39/test262.git main`.\n\n## 2. Triage every commit\n\nRead the commits, not just the changed-file list.\n\n| Signal | Meaning |\n| --- | --- |\n| only `.github/**`, `tools/**`, `package.json` | infra — zero impact on the run |\n| `features.txt` gained a line | a new feature; if Jint lacks it, it parks in `ExcludedFeatures` with a comment |\n| `src/**.case` / `src/**.template` | procedurally generated tests changed; read the generated output, not the template |\n| new files under `test/built-ins/**` or `test/language/**` | **the risky class** — go to step 3 |\n| a commit message naming a proposal, \"normative\", or an `ecma262#NNNN` | **stop and read the algorithm diff** |\n\nFor a small range, just read the new tests — `git show :test/path/to/new-test.js`. A test's `info:` block\nusually quotes the numbered algorithm verbatim, which is the fastest way to see what changed and the most\nreliable way to get argument-validation order right.\n\nFor each new behavioural test, check the engine **before** running the suite. `Jint.Repl` turns a 3-minute\nsuite run into a 10-second answer:\n\n```bash\ndotnet run --project Jint.Repl -c Release -- -f scratch.js -t 10 # always pass -t\n```\n\nWrite the assertions as plain `if (…) throw new Error('FAIL …')` — the REPL has no test262 harness. Strip the\n`$DONOTEVALUATE()` / `includes:` lines; for `flags: [async]` tests, assert on `.then(...)` callbacks.\n\n## 3. Normative changes — the part that actually costs time\n\n**The published spec can be behind test262.** A normative PR that reaches consensus gets test262 coverage\nwhile `tc39.es/ecma262` still renders the old algorithm, and an already-merged proposal's own page\n(`tc39.es/proposal-*/`) is frozen at its pre-merge text and will confidently show you the wrong steps. Both\nhappened on the `Promise.try` bump: the proposal page and the living spec agreed with each other and with\nJint, and all three were what the new tests were written to reject.\n\nFind the real change through the repo, not the rendered spec:\n\n```bash\ngh api -X GET search/issues -f q='repo:tc39/ecma262 ' \\\n --jq '.items[] | \"\\(.number) \\(.state) \\(.title)\"'\ngh pr view --repo tc39/ecma262 --json title,state,mergedAt,labels\ngh pr diff --repo tc39/ecma262 # the spec.html algorithm diff is the authority\n```\n\nLabels tell you the status: `has consensus` + `needs implementations` means implement it. `mergedAt: null` is\n**not** a reason to skip — AGENTS.md is explicit that where prose and test262 disagree, test262 at the pinned\nSHA wins.\n\nWhen you implement one:\n\n- Cite the document that owns the feature now. A merged proposal moves to `https://tc39.es/ecma262/#sec-...`;\n the anchors get renamed on the way in.\n- Add a `` naming the normative PR, so the next reader knows why the code and the current published\n prose disagree.\n- **Re-check the paths the reorder newly reaches.** Moving a step can expose a latent bug that the old\n ordering made unreachable — see the gotchas below, where hoisting a call above a capability construction\n turned a dormant `Promise.try()` crash into a live one.\n\n## 4. Bump, build, run\n\n```bash\n# edit SuiteGitSha, then:\ndotnet test -c Release Jint.Tests.Test262/Jint.Tests.Test262.csproj\n```\n\nThe build regenerates before it compiles; no separate generate step. ~3 minutes, ~99.9k tests. No runner\ntimeout needed — the engine defaults to 30 s per test.\n\nVerify the regeneration actually happened rather than trusting a green run over a stale `Generated/`:\n\n```bash\ngrep -c \"\" Jint.Tests.Test262/Generated/Tests262Harness.Tests.language.generated.cs\n```\n\nA negative parse test appears **twice** per file (strict + sloppy). Deleted upstream tests should be gone.\n\nThen, because a spec fix moves engine behaviour that unit tests pin:\n\n```bash\ndotnet test -c Release Jint.Tests/Jint.Tests.csproj\ndotnet test -c Release Jint.Tests.PublicInterface/Jint.Tests.PublicInterface.csproj\n```\n\n## 5. Fixing what fails\n\nFailure output contains the failing script — strip the line numbers to reproduce it in `Jint.Repl`. Put a\nregression test in `Jint.Tests` for anything test262 does **not** cover (test262 tests the spec, not Jint's\ninternals; a crash on an input no test262 test exercises still needs a pin).\n\n## 6. Decide whether there is a PR at all\n\nIf the suite is green with only the pin moved, there is nothing to ship but a one-line pin bump — say so and\nask before opening a PR. A bump that needs engine fixes is a real PR: pin + fix + regression tests, targeting\n`sebastienros/jint` `main`.\n\n```bash\ngh pr create --repo sebastienros/jint --head : --base main\n```\n\nKeeping the local suite fork current is a separate, optional courtesy:\n\n```bash\ncd ../test262 && git fetch upstream && git merge --ff-only upstream/main # then push origin main if wanted\n```\n\n## Gotchas this task has actually hit\n\n- **Author date lies about ordering.** `%ad` is not topology; use `%cd` or `--is-ancestor`.\n- **The proposal page is frozen at merge.** `tc39.es/proposal-promise-try/` still shows the pre-normative\n algorithm. Never cite it as current for a merged feature.\n- **`spec.html` is too big for a fetch tool.** Asking a fetcher for one section of the living spec returns a\n truncated prefix and a confident \"not found\". Go through `gh pr diff` instead.\n- **A reorder exposes latent bugs.** `Promise.try` moved `NewPromiseCapability` after the callback call; the\n argument-slicing that the old ordering never reached with zero arguments then crashed.\n- **`arguments.AsSpan()` is a trap in a built-in.** `ExpressionCache.ArgumentListEvaluation` hands the callee\n `Unsafe.As(object?[])` whenever the argument list is fully cached — *including the zero-argument\n case* — so `AsSpan()` throws `ArrayTypeMismatchException` (\"Attempted to access an element as a type\n incompatible with the array\"). Use `arguments.Skip(n)`, which copies element-wise and returns `[]` when\n there is nothing to take.\n- **`JsValue.Call` on a non-callable throws a CLR `ArgumentException`, not a JS `TypeError`.** Where the spec\n says `Call(F, V, args)`, write `GetCallable(f).Call(...)` so the failure is a `JavaScriptException` your\n `Completion` handling can turn into a rejection.\n- **`Promise`-shaped fixes need the abrupt path checked too.** `Completion(...)` wrapping means a throw\n inside the step becomes a rejection, while a throw from a step *outside* it propagates to the caller. Tests\n distinguish the two (`ctx-non-ctor.js` expects a synchronous `TypeError`; `throws.js` expects a rejection).\n","AGENTS.md":"# Agent Instructions for Jint\n\nJint is a JavaScript interpreter for .NET. It parses JavaScript using the Acornima library (AST), then interprets it directly — no bytecode generation or DLR usage. The pipeline is `Acornima parser → AST → interpreter → runtime → interop`, each AST node wrapped once in a `Jint*` interpreter class that `Engine` walks; the three stages, those wrapper classes and what they return — `Completion` for a statement, `JsValue` or `Reference` for an expression — are in [`Jint/Runtime/Interpreter/AGENTS.md`](Jint/Runtime/Interpreter/AGENTS.md#the-execution-pipeline).\n\nThis is the canonical instruction file for every agent working on this repository; `CLAUDE.md` imports it. Target and compare work against the **`main`** branch, which is also the PR target.\n\n## How these instructions are laid out\n\nThis file is the entry point and is kept small: it holds what every agent needs before its first edit,\nwhatever that edit turns out to be. Everything else lives in an `AGENTS.md` beside the code it governs.\n**Read the file on the row matching what you are about to do, before you touch that code.**\n\n| If you are about to… | Read first | What is in it, and what a violation costs |\n| --- | --- | --- |\n| change a signature or observable behaviour under `Jint/`, or anything outliving one evaluation — `Prepared`, `Options`, a snapshot, the event loop, an `*Async` entry | [`Jint/AGENTS.md`](Jint/AGENTS.md) | The key runtime types, the namespace map, the engine-source conventions (type co-location, the unsigned-cast bounds check, the code patterns, visibility), and where the frozen-contract table lives. Cost: a silent breaking change for embedders, or one engine's state leaking into another through a shared `Prepared