## Problem
The Windows variant of the `Execution tests > Executes external commands
> handles timeouts` test (`test/exec-tests.ts`) is flaky on CI. It ran:
```ts
exec.execute('powershell', ['-Command', '"sleep 5"'], {timeoutMs: 10})
```
The embedded double-quotes make `"sleep 5"` a **string literal** that
PowerShell just echoes and exits immediately — it never sleeps. The test
only "passed" by racing the 10 ms timeout against PowerShell's startup.
When PowerShell wins the race it returns `code: 0` / `stdout: "sleep 5"`
instead of the expected killed result, intermittently failing the
Windows `test` job.
(Spotted while verifying CI on #8737 — the only failure there was this
test, unrelated to that PR.)
## Fix
Use `Start-Sleep -Seconds 5`, which actually blocks, so the 10 ms
timeout deterministically kills it. The expected result block is
unchanged (`code: 1` is what `taskkill` yields for an externally-killed
process on Windows). Added a comment explaining the rationale, and fixed
the `timouts` → `timeouts` typo in both the Windows and POSIX test
names.
## Testing
- POSIX branch runs locally: `npx vitest run test/exec-tests.ts` → 22
passed.
- The Windows branch can only run on a Windows runner; the change is
confined to the command string and leaves the assertion identical.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This PR implements the source mapping for .NET compilers (C#, F#, VB.NET
and IL), supports CoreCLR, Crossgen2 and NativeAOT compilers.
- Add a parser that walks ECMA-335 metadata and Portable PDB sequence
points to build IL-offset-to-source mappings for .NET methods
- Load PDBs emitted by the .NET compiler after building the dll, and
then save the source mapping in the result
- Extend the .NET asm parser to match disassembly method signatures,
including generic types, generic methods, and inline root offsets, so
emitted asm lines inherit the correct source locations
- Use debug info emitted by the JIT `INLRT @ 0x##` as anchors to match
the offset
Showcase:
## Summary
Three related fixes prompted by driving the deployed MCP endpoint after
#8644 / #8685 merged:
1. **`list_libraries` match also searches version strings.** The natural
LLM query "find Boost 1.88" returned zero results —
`list_libraries({language:"c++", match:"boost 1.88"})` only matched
against `{id, name}`, so the version token never matched anything.
2. **HPPA + Go cross-compiler `instructionSet` retags.** Discovered via
`list_compilers(match="gcc 16", instructionSet="amd64")` returning
*only* `hppag1610` (HPPA cross-compiler) and missing plain `g161`
(x86-64 GCC). Two layered causes — HPPA had no entry in
`InstructionSetsList`, so the heuristic in `lib/instructionsets.ts`
defaulted HPPA cross-compilers to `amd64`; and 12 Go cross-compiler
groups (`386gl`, `arm32gl`, `arm64gl`, `mips*gl`, `ppc64*gl`, `riscvgl`,
`s390xgl`, `wasmgl`) had never been tagged at all.
3. **Defensive bucketing in MCP `pickLatest`.** Belt-and-braces fix:
bucket key is now `(lang, instructionSet, group)` so different compiler
families that happen to share an arch tag can't fight for the same
`latestPerMajor` slot.
## Changes
- `lib/mcp/tools/libraries.ts` — extend `applyMatch` haystack to include
`versions[].version` (human form, e.g. `"1.88.0"`) and `versions[].id`
(e.g. `"188"`).
- `lib/mcp/tools/compilers.ts` — `pickLatest` bucket key now includes
`c.group`.
- `types/instructionsets.ts` + `lib/instructionsets.ts` — new `'hppa'`
entry.
-
`etc/config/{ada,c++,c,d,fortran,gimple,objc++,objc}.amazon.properties`
—
`group.<gnathppa|gcchppa|cgcchppa|gdchppa|gimplehppa|objcppgcchppa|objchppa>.instructionSet=hppa`.
- `etc/config/go.amazon.properties` — explicit `instructionSet=` for all
13 Go arch groups (12 cross + amd64gl for symmetry).
- `test/mcp/mcp-tests.ts` — covers the bucketing-by-group case.
- `test/instructionsets-tests.ts` — covers the hppa target-string
branch.
## Follow-up
#8690 — drop the `lib/instructionsets.ts` path-based heuristic entirely
in favour of required `instructionSet` properties (the path branch is
Amazon-install-specific and silently mistags compilers on any non-Amazon
layout).
## Test plan
- [x] `npm run test -- --run mcp` — passes (existing + 2 new)
- [x] `npm run test -- --run instructionsets` — passes (existing + 1
new)
- [x] `npm run test:props` — 90/90 pass
- [x] `make pre-commit` — exits 0
- [ ] Drive the staging endpoint with `list_libraries({language:"c++",
match:"boost 1.88"})` and confirm Boost is returned with its versions.
- [ ] Drive the staging endpoint with `list_compilers({match:"gcc 16",
instructionSet:"amd64", latestPerMajor:true})` and confirm `g161`
(x86-64) appears and `hppag1610` does not.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Expose Compiler Explorer's compile, list, shortlink and asm-docs APIs
via a Model Context Protocol (MCP) endpoint mounted at `/mcp`. This lets
MCP-aware clients (Claude, etc.) drive CE directly as a tool.
## Tools exposed at `/mcp`
- **`compile`** — compile source and return assembly / stdout / stderr,
with optional execution.
- `compiler` is **optional**; falls back to the language's
`defaultCompiler` from `list_languages` ("compile this hello world in
C++" is one call).
- `libraries[].version` accepts **either** the version id (`"188"`) or
the human form (`"1.88.0"`) — both work.
- When `execute: true` and the build fails,
`buildResult.stdout`/`stderr` carry the real compiler diagnostics with
**ANSI codes stripped** so an LLM caller sees clean text.
- Caps: `maxAsmLines` / `maxStdoutLines` / `maxStderrLines` with
truncation flags + total counts.
- **`list_compilers`** — with `language`, `instructionSet` (closed enum
from `InstructionSetsList`), `match` (case-insensitive AND-of-tokens;
numeric/dotted-version tokens treated as version-prefix), `lean: true`,
`maxResults`, `latestPerMajor: true`, and `includeExperimental: true`.
- Hard cap of 200 entries on lean responses with a refinement hint —
prevents the unfiltered call from overflowing.
- Each entry exposes `releaseTrack` (`stable | nightly | prerelease |
experimental`) and `supportsExecute` / `supportsBinary`.
- **`list_libraries`** — with `match`, `lean`, `maxResults` (same
lean-cap behaviour).
- **`list_languages`** — minimal listing including `defaultCompiler` and
`compilerCount` per language.
- **`generate_short_url`** — returns `{url}`. Library versions are
normalised before saving.
- **`get_shortlink_info`** — returns saved sessions in the **same shape
`compile` accepts** (`{compiler, options, libraries:[{id, version}]}`)
for direct round-tripping. Multi-pane shortlinks (executors,
conformance, CMake trees) are flattened to the basic compile inputs.
- **`lookup_asm_instruction`** — `instruction_set` is a closed enum
derived from the registered providers (no hand-listed enum values; one
source of truth in `lib/asm-docs/`).
## Implementation
- New `lib/mcp/` module wiring `@modelcontextprotocol/sdk` into the
existing Express router via `StreamableHTTPServerTransport` (stateless
mode — one server per request).
- `lib/mcp/utils.ts`: tokenised `match` with version-prefix matching for
numeric/dotted-version tokens (so `"gcc 14.1"` matches `"gcc 14.1"` and
`"gcc 14.1.0"` but NOT `"gcc 14.10"` or `"gcc 14.0.1"`); `applyCap` with
both per-call lean degradation and an absolute hard cap; `truncateLines`
strips ANSI escapes via the existing `filterEscapeSequences` helper from
`lib/utils.ts`.
- `lib/mcp/library-utils.ts`: `normaliseLibraryVersion` and
`normaliseRequestLibraries` — single source of truth for "accept id or
human version" semantics, used by both `compile` and
`generate_short_url`.
- Schema descriptions are tight (LLM context cost matters) and derive
closed-set enums programmatically from `InstructionSetsList`,
`RELEASE_TRACKS`, and a new `availableAsmDocsKeys` export — no
hand-listed values that can rot.
- Refactor `StorageBase` static helpers (`encodeBuffer`, `isCleanText`,
`getSafeHash`) to module-level functions with type-checked input so MCP
tools can build shortlink hashes without instantiating a storage
backend.
- Expose `ApiHandler.compileHandler` and split out
`getAvailableLanguages()` so MCP can reuse the same code paths the REST
API uses; new `ApiHandler.getDefaultCompilerFor()` for the
compile-default-compiler resolution.
- Browser-friendly CORS on `/mcp`: OPTIONS preflight advertises
`Access-Control-Allow-Methods: POST, OPTIONS` (the shared `cors`
middleware doesn't set Methods); 405 responses on other verbs use the
same Allow header.
- `docs/API.md`: clarify that `/api/shortener` requires a JSON object
body (the prior docs implied but didn't state it).
## Tester feedback addressed
A Claude tester drove the staging deployment through several rounds;
full thread in PR comments. Round-by-round refinements:
- Compile diagnostics surfaced on execute-mode build failures (the
original "silent `Build failed` with empty stderr" bug).
- `execute: true` schema description rewritten to reflect the actual
behaviour.
- Library `version` accepts both forms; clean errors when neither
matches with a sample of available versions.
- `latestPerMajor` rebuilt on top of the `releaseTrack` field added in
#8685, with `includeExperimental` opt-in for c++ proposal forks.
- Lean mode (`lean: true`) for catalog browsing, plus a hard 200-item
cap so even unfiltered calls don't overflow the host.
- Tokenised `match` with version-prefix semantics for
numeric/dotted-version tokens. **Behaviour change** vs the old
`/api/compilers?fields=...` text matching: bare numeric tokens are now
treated as version segments — `"2024"` no longer substring-matches
inside `"v2024beta"`, and `"14.1"` no longer wrongly matches `"14.0.1"`.
Strict improvements but worth a release-note line for callers depending
on the prior loose behaviour.
- ANSI escape code stripping from compile output.
- `instructionSet` as a structured filter (instead of relying on `match`
strings).
- `supportsExecute` / `supportsBinary` on `list_compilers` so an agent
knows whether `execute: true` will work without trying.
- `compilerCount` per language so an agent can tell well-stocked vs
niche languages at a glance.
- Compiler-not-found / library-not-found errors point at the right
`list_*` tool.
## Depends on
#8685 (releaseTrack metadata on `CompilerInfo`) — merged.
## Test plan
- [x] `npm run test -- --run mcp release-track` — all pass (78 + 22)
- [x] `npm run test-min` — full minus expensive, all green
- [x] `make pre-commit` — exits 0
- [x] Multi-round driving on staging via the live MCP endpoint,
including: default-compiler hello-world (no compiler arg), human-form
library version (`"1.88.0"`), broken-compile-with-execute (verifies
buildResult), compile+run with stdin, compile+library Boost 1.90,
parallel `-O0` vs `-O3` diff, `list_compilers latestPerMajor` for
c++/rust/go/csharp, `list_libraries match boost/fmt/json`,
`lookup_asm_instruction MOV amd64`, full `generate_short_url` →
`get_shortlink_info` → re-`compile` round-trip with library
normalisation.
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Matt Godbolt <mattgodbolt@hudson-trading.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
## Summary
Adds a structured `releaseTrack: 'stable' | 'nightly' | 'prerelease' |
'experimental'` field on `CompilerInfo` so consumers can distinguish
release tracks that aren't currently separable from the existing
`isSemVer` / `isNightly` / `semver` fields.
Today every compiler with a non-numeric semver and `isNightly=true`
looks the same from the outside: Rust nightly, Rust beta, gcc snapshot,
and gcc's various experimental forks (`gcontracts-trunk`,
`gcc-modules-trunk`, `glambda-p2034-trunk`, ...) all share the same
shape. Anything that wants to ask "what's the canonical newest build of
language X" — a UI badge, the upcoming MCP `latestPerMajor` knob
(#8644), etc. — has no way to tell those apart.
## Implementation
- **Heuristic** in `lib/release-track.ts` driven by `asSafeVer` + the
existing `isSemVer`/`isNightly` flags. Real semvers with a prerelease
segment (e.g. micropython `1.28.0-preview`) are flagged `prerelease`;
semvers containing `trunk`/`main` and the literal `nightly` tag go to
`nightly`; bare `beta`/`alpha`/`rc` tags go to `prerelease`; `isNightly`
with anything else (the c++ experimental forks) goes to `experimental`;
everything else stays `stable`.
- **Override:** `compiler.releaseTrack=` / `group.releaseTrack=` in
`.properties` for cases the heuristic can't reach from structural
fields. Used here for `rustccggcc-master` / `mrustc-master`, where
"master" lives in the compiler id but not the semver field.
- **Backfill** in `loadPrediscovered()` so cached discovery JSON written
before this field existed doesn't break, and so a hand-edited invalid
value gets re-inferred rather than violating the type contract.
- **Tests:** 18 unit tests covering each rule + edge cases (whitespace,
mixed case, prerelease segments) and the `isReleaseTrack` type guard.
## API exposure
`releaseTrack` is on `CompilerInfo` so it appears via
`/api/compilers?fields=all`. It is **not** in the default field set, so
existing API responses are unchanged. UI consumers can opt in.
## Why this is a separate PR
This started as a piece of #8644 (MCP endpoint) — the MCP
`list_compilers` `latestPerMajor` knob needs this distinction to give
clean answers ("newest GCC" should not return a sea of experimental
forks). Rather than hack around the missing metadata in just the MCP
layer, the metadata belongs at the source where other features (UI
badging, etc.) can consume it. #8644 will rebase on top of this.
## Test plan
- [ ] `npm run test -- --run release-track` — 18/18 pass
- [ ] `npm run test:props` — 90/90 pass
- [ ] `make pre-commit` — exits 0 (pre-existing warnings only)
- [ ] Manual sanity check on staging:
`/api/compilers/c%2B%2B?fields=all` returns `releaseTrack` for each
compiler
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
## Summary
bronto-refactor emits the refactored source on stdout. The default
`parseOutput` pipeline includes a `FileWithLineMessage` matcher whose
regex (`SOURCE_WITH_FILENAME` in `lib/utils.ts`) is permissive enough to
mistake any C++ member call with a numeric first argument — e.g.
`r.fetch_add(2, std::memory_order_relaxed);` — for a `filename:line:`
reference, treating `r.fetch_add` as a filename and `2` as a line
number. The result was fake red error squigglies in the editor, with the
trailing `, std::memory_order_relaxed);` shown as the diagnostic
message.
`BrontoRefactorTool` now overrides `parseOutput` to drop
`FileWithLineMessage`. `SourceWithLineMessage` is kept so genuine
`<source>:N:M:` diagnostics on stderr still surface.
Reported via the web UI when running bronto-refactor on this:
```cpp
#include <atomic>
void foo(std::atomic<int>& r) {
r.fetch_add(2, std::memory_order_relaxed);
r.fetch_add(4, std::memory_order_relaxed);
}
```
## Out of scope
The `SOURCE_WITH_FILENAME` regex in `lib/utils.ts:154` is genuinely too
loose — any tool whose stdout is source-like (formatters, refactorers)
can hit this. Tightening it (require an extension, or `:`-only
separator) is a separate change since it touches every compiler/tool
that relies on `parseOutput`.
## Test plan
- [x] Added `test/tool-tests.ts` case asserting refactored source
produces no tags.
- [x] Added a second case asserting a real `<source>:N:M:` diagnostic on
stderr is still tagged (so we didn't over-blunt the parser).
- [x] Verified the first test fails on `main` and passes with the fix.
- [x] `npm run ts-check`, `npm run lint`, `npm run test -- --run
tool-tests` all pass.
- [ ] Confirm in the web UI that the original repro no longer shows
squigglies.
cc @fowles
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
## Summary
- Fixes#8622: adds assembly documentation entries for the RISC-V `sgt`
and `sgtu` pseudoinstructions so the hover/"View assembly documentation"
feature works instead of showing an error.
- `sgt rd, rs, rt` expands to `slt rd, rt, rs`; `sgtu rd, rs, rt`
expands to `sltu rd, rt, rs`. Entries follow the same shape as the
existing `SGTZ` pseudo entry.
## Test plan
- [x] `npx vitest run test/handlers/asm-docs-tests.ts`
- [x] `npx tsc --noEmit`
- [x] `npm run lint` (no new errors)
---
This PR is authored by an LLM (Claude) acting on behalf of @mattgodbolt.
---------
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
## Summary
- Fixes the property parser regex to allow `+` in key names (e.g.
`abc+def=etc`)
- The regex from #8387 used `[^=+]+` for key matching, which excluded
`+` from key names entirely
- Changed to a lazy `.+?` match so `+` is only treated as the `+=`
operator when immediately before `=`
This is a small targeted fix and does not address all edge cases with
the `+=` syntax.
## Test plan
- [x] Added test: `abc+def=etc` correctly sets key `abc+def` to `etc`
- [x] Added test: `abc=def+ghi` correctly sets key `abc` to `def+ghi`
- [x] All existing `+=` append tests continue to pass
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
A `catchswitch` instruction has the form:
catchswitch within none [label %catch.start] unwind to caller
The LLVM IR parser then extracts the labels out of this expression.
However, the regex is too greedy, and (incorrectly) matches
`%catch.start]`. We update the regex to match what LLVM's lexer does.
The [language reference](https://llvm.org/docs/LangRef.html#identifiers)
states that quoted identifiers can include `\xx` escapes, however as far
as I can tell [that is *not*
true](413cafa462/llvm/lib/AsmParser/LLLexer.cpp (L391-L421)),
so I have elected not to support them.
For the following program (targetting WASM, compiled with
`-fwasm-exceptions`):
```c
void bar(int x);
void foo() {
try {
bar(1);
} catch(int x) {
}
}
```
**Before:**
<img width="1492" height="411" alt="A CFG of the above program. The
catch block is entirely disconnected from the main part of the graph."
src="https://github.com/user-attachments/assets/ad9038cc-f372-4109-bc25-328537bcea88"
/>
**After:**
<img width="1286" height="639" alt="A CFG of the above program. The
catch block is now correctly connected to the rest of the graph."
src="https://github.com/user-attachments/assets/27cce7b3-dd67-4c1c-928c-93f7eaa53fa2"
/>
The `links` field in `ParsedAsmResultLine` and the `AsmResultLink` type
have been unused since 2019 when clickable address links were replaced
by the labels system. This just removes the dead code.
Closes#8251
*(I'm Molty, an AI assistant acting on behalf of @mattgodbolt)*
Closes#5178
## Problem
NVCC embeds the CUDA fat binary blob in the host-side x86 assembly
inside a `#APP`/`#NO_APP` inline-assembly block, under a label called
`fatbinData`. In a realistic kernel this can be 100+ lines of `.quad`
hex values — a wall of noise before any user-readable code.
Example: https://godbolt.org/z/W3YMcq8oY
## Fix
Per-compiler pre-processing step in `NvccCompiler.processAsm()`: before
the host assembly reaches the ASM parser, any `#APP`/`#NO_APP` block
containing a `.nv_fatbin` section is stripped out entirely.
- Only `.nv_fatbin` blocks are removed; genuine user inline-assembly
blocks (which also use `#APP`/`#NO_APP` but without `.nv_fatbin`) are
left intact.
- Intentionally NVCC-specific — no changes to the base `AsmParser`, no
false-positive risk for other compilers.
- Stripping happens before `findUsedLabels` runs, so `fatbinData`
naturally disappears as unreferenced without any special-casing in the
parser's label-filtering logic.
- Gated on the existing Labels filter: with no filters active everything
remains visible; with Labels on the blob disappears.
## Testing
**New compiler unit tests** (`test/compilers/nvcc-tests.ts`):
- Strips `#APP`/`#NO_APP` blocks containing `.nv_fatbin`
- Preserves `#APP`/`#NO_APP` blocks without `.nv_fatbin` (user inline
asm)
- Handles multiple mixed blocks correctly
- No-op when no `#APP` blocks present
- Gracefully handles malformed unclosed blocks
**New parser filter-case**
(`test/filters-cases/nvcc-x86-host-example.asm`): representative NVCC
12.0 host assembly (real 15-line fat binary, boilerplate functions,
`.nvFatBinSegment` section) with nine filter-combination snapshots
documenting parser behaviour in isolation. These correctly show that the
**base parser itself does not filter `fatbinData`** — that's the
compiler pre-processor's job.
All 767 tests pass.
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
Closes#6319Closes#6320
Adds two new opt-in filter checkboxes to the LLVM IR view's **Filters**
dropdown:
### Hide Declarations (off by default)
Filters external function declaration lines (lines starting with
`declare`). These are forward declarations of external functions and are
often noise when focusing on user code.
**Off by default** — as noted in #6319, `declare` lines are part of
valid IR and are needed when copying output into other tools such as
`opt`, `llc`, `alive2`, etc.
### Hide Library Functions (off by default)
Filters compiler-generated library function thunks — specifically
function definitions whose name matches patterns like `@jfptr_*` (used
by Julia). These are boilerplate wrapper functions that aren't useful
when reading IR.
**Off by default** for the same reason — these are real function
definitions in the IR.
Both filters follow the same pattern as existing IR filters (debug info,
metadata, attributes, comments). Unit tests added in
`llvm-ir-parser-tests.ts` covering filter-on, filter-off, and
preservation of unaffected lines.
*(I'm Molty, an AI assistant acting on behalf of @mattgodbolt)*
---------
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
Inline the escape_html type instead of importing from tom-select's
internal dist/types/ path, which was removed in v2.5.1. The type is just
(str: string) => string, so there's no need to depend on the package's
internal file layout.
Also fix missing iframe title attributes in test/embedding.html.
---------
Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
m68k GAS uses `|` as the comment character instead of `#`.
The base asm parser doesn't recognise this, so inline asm source
location markers (e.g. `| 2 "file.c" 1`) leak through into the output
instead of being filtered.
Repro on godbolt.org: https://godbolt.org/z/vYneWc8Tf
---------
Co-authored-by: Patrick Quist <partouf@gmail.com>
## Summary
- When multiarch compilers (Rust, Zig, etc.) target a non-host
architecture (e.g. `--target=aarch64-unknown-linux-gnu`), GNU `objdump`
fails because it cannot disassemble foreign-arch binaries, producing
`<No output: objdump returned 1>`
- Adds a `llvmObjdumper` config property that switches to `llvm-objdump`
when the compilation targets a non-x86 instruction set, since
`llvm-objdump` can auto-detect the target architecture from the binary
itself
- All multiarch compilers benefit from this generically via
`BaseCompiler.getObjdumperForResult()` — no per-compiler special-casing
needed
## Changes
- **`types/compiler.interfaces.ts`** — Add `llvmObjdumper` to
`CompilerInfo`
- **`lib/compiler-finder.ts`** — Read `llvmObjdumper` from config
- **`lib/base-compiler.ts`** — Add `getObjdumperForResult()` method and
refactor `objdump()` to use it
- **`etc/config/rust.defaults.properties`** — Set
`llvmObjdumper=llvm-objdump`
- **`etc/config/zig.defaults.properties`** — Set
`llvmObjdumper=llvm-objdump`
- **`test/objdumper-tests.ts`** — Add 6 tests for cross-architecture
objdumper selection
## Test plan
- [x] `npm run ts-check` passes
- [x] `npm run lint` passes
- [x] All related tests pass (301 tests across 27 files)
- [x] Smoke test: configure a Rust compiler with
`--target=aarch64-unknown-linux-gnu` and verify `llvm-objdump` is used
instead of GNU `objdump`
Fixes#5593
Add ca65 as a standalone assembler under the Assembly language, reusing
the existing cc65 toolchain installations (2.17, 2.18, 2.19, trunk).
ca65 generates a listing file with full macro expansion (`-x -x`) so
users can debug macro output — the primary use case from the feature
request.
**What's included:**
- `Ca65Compiler` class — runs ca65, captures the listing output
- `AsmParserCa65` — parses the ca65 listing format (address, hex bytes,
source)
- Config for all 4 existing cc65 versions as ca65 assemblers
- Include paths set to each version's `asminc` directory
**How it works:**
Since ca65 produces object files in cc65's custom format (not ELF), we
can't objdump them. Instead, we use ca65's `-l` (listing) flag with `-x
-x` (full macro expansion) and `--list-bytes 0` (unlimited hex bytes per
line). The listing shows addresses, generated bytes, and expanded source
— exactly what users need for macro debugging.
Closes#7118
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
Addresses #4128 — cleans up commented-out code and improves code quality
in `LlvmPassDumpParser`.
**Commit 1: Remove commented-out code**
Remove unused fields (`label`, `instruction`), dead `maxIrLines`
configuration code, stale debug logging (`console.log`/`console.dir`),
and obsolete early-exit logic. The `compilerProps` constructor parameter
was only used by the commented-out code, so remove it and update all
call sites.
**Commits 2–4: Add comprehensive test suite**
50 tests locking in existing behaviour across all parser methods:
`breakdownOutputIntoPassDumps`, `breakdownPassDumpsIntoFunctions`,
`breakdownIntoPassDumpsByFunction`, `matchPassDumps`,
`associateFullDumpsWithFunctions`, and end-to-end `process()`. Covers
edge cases like loop dumps, `(invalidated)` passes, IR→MIR transitions,
CIR headers, and full-module mode.
**Commits 5–6: Clean up code style**
- snake_case → camelCase throughout (`raw_passes`, `final_output`,
`function_name`, etc.)
- Mark all regex fields `readonly`
- Replace `.map()` used for side effects with `for...of` loop
- Replace `[_, entry]` destructuring with `Object.values()`
🤖 Generated by LLM (Claude, via OpenClaw)
Introduce a += operator in property file parsing that appends values to
existing string properties. This allows splitting long property values
across multiple lines for improved readability.
Example:
group.compilers=comp1:comp2:comp3
group.compilers+=:comp4:comp5:comp6
Error handling:
- Logs error and skips if += is used on an undefined property
- Logs error and skips if += is used on a non-string property
Includes unit tests for the new functionality.
<!-- THIS COMMENT IS INVISIBLE IN THE FINAL PR, BUT FEEL FREE TO REMOVE
IT
Thanks for taking the time to improve CE. We really appreciate it.
Before opening the PR, please make sure that the tests & linter pass
their checks,
by running `make check`.
In the best case scenario, you are also adding tests to back up your
changes,
but don't sweat it if you don't. We can discuss them at a later date.
Feel free to append your name to the CONTRIBUTORS.md file
Thanks again, we really appreciate this!
-->
Enable Biome's `organizeImports` with groups matching the original
ESLint `import/order` configuration:
1. **Node builtins** (`node:fs`, `path`, etc.)
2. *(blank line)*
3. **Third-party packages** (`express`, `@sentry/node`, etc.)
4. *(blank line)*
5. **Local/relative imports** (`../foo.js`, `./bar.js`, aliases)
This resolves the inconsistency where Biome wasn't enforcing import
grouping, meaning new files would lose the blank-line separation that
the old ESLint config enforced.
### Impact
- **354 files** updated out of 738 checked (~48%)
- **+188 / -240 lines** (net -52) — almost entirely single blank line
additions/removals between import groups
- No import reordering; purely group separator consistency
Fixes#7373🤖 Generated by LLM (Claude, via OpenClaw)
## Summary
- Fixes#8364: clang 21 debug info (`.debug_loclists` etc.) was passing
through directive+label filters
- The label processor's `endBlock` regex only matched `.cfi_endproc`,
missing section boundaries (`.section`, `.data`, `.text`) that the main
parser already handles — so `currentLabelSet` was never cleared across
sections, causing weak label associations to leak from used labels (e.g.
jump tables in `.rodata`) into debug sections
- Passes `startBlock` and `endBlock` from the parser into `LabelContext`
instead of using hardcoded inline regexes, and clears `currentLabelSet`
on `endBlock`
## Test plan
- [x] Added `bug-8364.asm` test case with a jump table followed by
`.debug_loclists` section
- [x] Verified debug labels appear in unfiltered output but are excluded
from directive+label filtered output
- [x] Full test suite passes (2106 tests, no regressions)
- [x] TypeScript type check clean
- [x] Lint clean
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Summary
Replaces the Python `propscheck.py` validation script with TypeScript
code that:
- Uses a testable validator module (`lib/properties-validator.ts`)
- Has comprehensive unit tests (71 tests in
`test/properties-validation-tests.ts`)
- Integrates with the existing property loading infrastructure
- Runs as part of the normal test suite
## Changes
- **New validator module** (`lib/properties-validator.ts`):
- Raw file validation: duplicate keys, empty list elements, typos,
suspicious paths
- Orphan detection: compilers, groups, formatters, tools, libraries
- Cross-file duplicate compiler ID detection
- Disabled allowlist support (`# Disabled: id1 id2`)
- Invalid property format detection (leverages `parseProperties()` with
new `collectErrors` option)
- Missing compilers list detection for language files
- **Property library enhancement** (`lib/properties.ts`):
- Added `collectErrors` option to `parseProperties()` for structured
error collection
- **New npm script**: `npm run test:props` for quick property validation
- Set `CHECK_LOCAL_PROPS=true` to include `.local.properties` files
- **Updated references**:
- CI workflow no longer calls propscheck.py
- Pre-commit hook uses `npm run test:props`
- CE Properties Wizard uses the new validation
- **Removed**: `etc/scripts/util/propscheck.py` and `propschecktest.py`
## Test plan
- [x] All 71 unit tests pass
- [x] Integration tests validate real config files
- [x] `npm run test:props` works standalone
- [x] CE Properties Wizard validation works
- [x] CI passes
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Summary
- Replaces `Record<any, any>` with `CompilationInfo` for the
`compilationInfo` parameter in tooling files
- The `CompilationInfo` type was already imported in 2 of 3 files but
not used
- Follows up on #8407 which fixed the same issue for `tools` type
## Files changed
- `compiler-dropin-tool.ts` - use existing import
- `sonar-tool.ts` - use existing import
- `microsoft-analysis-tool.ts` - add import
- `test/tool-tests.ts` - cast mock objects at declaration
## Test plan
- [x] `npm run ts-check` passes
- [x] `npm run test-min` passes
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Summary
- Fixed the `/api/tools/:language` API endpoint to correctly return the
`name` field
- The `BaseTool` class stores tool properties in a nested `tool`
property, but the API handler was incorrectly accessing `name`,
`languageId`, and `stdinHint` directly on the class instance instead of
via `tool.tool.*`
- Added tests to verify the tools endpoint returns the expected fields
Fixes#8399
## Test plan
- [x] Added unit test that verifies `name` field is included in response
- [x] Added test for empty tools list
- [x] All existing tests pass
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Summary
- When an absolute path prefix is provided to `temp.mkdir()` or
`temp.mkdirSync()`, use it directly instead of joining with
`os.tmpdir()`
- This supports use cases where compilers need temporary directories in
specific locations (e.g., shared NFS drives for remote compilation)
- Existing callers all use relative prefixes, so this is fully backwards
compatible
## Test plan
- [x] Added tests for both `mkdir` and `mkdirSync` with absolute paths
- [x] Verified existing tests still pass
- [x] Checked all callers use relative paths (no behaviour change)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Summary
- Fix externalparser not working with prediscovered compilers (e.g.,
MicroPython)
- The `externalparser.props` function was lost during JSON
serialization, causing `exe` path to be undefined
- Now stores `exe` and `args` directly on the externalparser object
- Removes the unused `props` function pattern from externalparser
- Adds proper TypeScript typing for externalparser
- Improves error messages to include compiler ID
- Adds delay before process.exit to allow Loki logs to flush
## Test plan
- [x] TypeScript type check passes
- [x] Linter passes
- [x] Unit tests pass
- [ ] Deploy to staging and verify MicroPython compilers work
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
The compiler output pane only links error messages to the source editor
when a filename is given. `parseRustOutput` didn’t parse the filename,
so Rust error messages were never linked.
This PR also simplifies the regex used to parse the `-->
filename:line:column` line in the `rustc` output. As far as I’m aware
(and I checked the history of the corresponding output in the `rustc`
source), the output format will always be `--> filename:line:column` and
not anything else accepted by the previous regex (no parentheses around
the line number, the column is not optional).
The PTX emitted can sometimes be of the form:
```
{ code
}
```
Later on if the parser sees that the current and last line were closing
and opening braces, it drops both lines. This prevents any single-line
instructions from showing up. This PR changes the logic to make opcodes
on the same line as opening braces valid, and also adds unit tests for
matching.
## Summary
This PR makes URL serialization logic available to Node.js contexts
(like Cypress tests) and replaces a hard-coded 4812-character base64 URL
in tests with programmatically generated state. This builds on the
shared utilities refactoring from #8246.
### Changes
#### 1. Extract URL Serialization to Shared Module
**Problem:** URL serialization code depended on GoldenLayout's
browser-only ConfigMinifier, preventing Cypress spec files from
importing it (they load in Node.js before running in browser).
**Solution:** Created `shared/url-serialization.ts` with a
Node-compatible ConfigMinifier reimplementation.
**Technical Details:**
- Reimplemented GoldenLayout's ConfigMinifier without browser
dependencies
- Moved serialization functions (`serialiseState`, `deserialiseState`,
`risonify`, `unrisonify`) to shared module
- Moved minification functions (`minifyConfig`, `unminifyConfig`) to
shared module
- Updated `static/url.ts` to use shared module instead of GoldenLayout
- Added comprehensive test coverage in `test/url-serialization.ts`
**Files:**
- **New:** `shared/url-serialization.ts` (~279 lines)
- **Modified:** `static/url.ts` (removed ~30 lines, eliminated
GoldenLayout dependency)
- **New:** `test/url-serialization.ts` (~96 lines)
#### 2. Replace Hard-coded Cypress URL with Programmatic State
**Before:** A hard-coded 4812-character base64 URL containing state for
all panes
```typescript
cy.visit('http://localhost:10240/#z:OYLghAFBqd5TB8IAsQGMD2ATApgUWwEsAXTAJwBoiQIAzIgG...');
```
**After:** Programmatically generated state using
`buildKnownGoodState()` function
```typescript
const state = buildKnownGoodState();
const hash = serialiseState(state);
cy.visit(`http://localhost:10240/#${hash}`, {...});
```
**Benefits:**
- Human-readable, maintainable test state
- Programmatic generation from `PANE_DATA_MAP` keys
- Layout optimized with 8 panes per row
- Produces identical compressed URL format
- Much easier to add/modify panes in the future
#### 3. PANE_DATA_MAP Consistency Improvements
Updated `PANE_DATA_MAP` to use component names exactly as registered
with GoldenLayout:
**Key renames:**
- `preprocessor` → `pp`
- `llvmir` → `ir`
- `pipeline` → `llvmOptPipelineView`
- `mir` → `rustmir`
- `hir` → `rusthir`
- `macro` → `rustmacroexp`
- `core` → `haskellCore`
- `stg` → `haskellStg`
- `cmm` → `haskellCmm`
- `dump` → `gccdump`
- `tree` → `gnatdebugtree`
- `debug` → `gnatdebug`
**Added panes:** `codeEditor`, `compiler`, `conformance`, `output` (were
missing from map)
**Re-enabled tests:**
- `yul` pane test (was commented out, now fixed)
- `clojuremacroexp` pane test (was commented out, now fixed)
- `cfg` pane test (had TODO, now removed)
**Why this matters:** The `buildKnownGoodState()` function uses
`Object.keys(PANE_DATA_MAP)` as the `componentName` property, so keys
must match the actual registered component names for GoldenLayout to
find them.
## Test Plan
- [x] All Cypress tests pass (confirmed by @mattgodbolt)
- [x] TypeScript compilation passes (`npm run ts-check`)
- [x] Linting passes (`npm run lint`)
- [x] URL serialization tests pass (3/3 tests)
- [x] Pre-commit hooks pass
- [x] Related vitest tests pass
## Dependencies
- Builds on #8246 (shared utilities refactoring - already merged)
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
## Summary
Moves `static/assert.ts` and `static/rison.ts` to `shared/` directory to
make them available to both frontend and backend code without browser
dependencies. Updates all import paths across the codebase (~47 files).
## Motivation
This refactoring eliminates browser dependencies in these utilities,
allowing them to be imported by Node.js contexts (like Cypress test
files) without causing module load failures. This is a prerequisite for
upcoming Cypress test improvements.
## Changes
- Move `static/assert.ts` → `shared/assert.ts`
- Move `static/rison.ts` → `shared/rison.ts`
- Update `biome.json` to allow `hasOwnProperty` in `shared/` directory
- Update all imports across `static/`, `lib/`, and `test/` directories
(47 files changed)
## Benefits
- No functional changes, purely a code reorganization
- Makes these utilities accessible to both frontend and backend without
circular dependencies
- Enables future Cypress improvements that require these utilities in
Node.js context
- All tests pass ✓ (699 tests)
## Test Plan
- [x] TypeScript compilation passes
- [x] Linting passes
- [x] All unit tests pass (699 tests)
- [x] Pre-commit hooks pass
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
## What
Adds support for seeing Yul (Solidity IR) as intermediate output when
compiling Solidity.
This PR also enables that view for the Resolc compiler.
### Main Additions
- [x] Support viewing Yul in a supplementary view
- Solidity compilers can enable this by setting
`this.compiler.supportsYulView = true` in the compiler's constructor
- If custom processing of the Yul output or the Yul output filename is
needed, the compiler can override `processYulOutput()` or
`getYulOutputFilename()`
- [x] Enable the Yul view for Resolc
- [x] Implement a Yul backend option for filtering out debug info from
the output
### Notes
Source mappings are currently not handled for Yul -> Solidity.
## Overall Usage
### Steps
* Choose Solidity as the language
* Choose a Resolc compiler
* View intermediate results:
* Yul
* (Hide/show debug info by toggling "Hide Debug Info" in the Yul view
filters)
## Screenshots
<img width="1502" height="903" alt="ce-yul-view"
src="https://github.com/user-attachments/assets/ccc897e2-cd8d-4c33-962c-522d60b63134"
/>
## Summary
- Updates vitest and @vitest/coverage-v8 from 2.1.8 to 4.0.1
- Fixes test mocks to work with vitest 4.0's constructor support
requirements
## Changes
Vitest 4.0 now supports `vi.fn()` being used as constructors, which
means arrow functions can no longer be used in mock implementations that
will be called as constructors.
### Key refactorings:
- **Class-based mocks in vi.mock()**: Defined mock classes directly in
`vi.mock()` factories instead of using `.mockImplementation()` with
arrow functions
- **Shared mock implementations**: Created shared `vi.fn()` instances
that can be configured per-test, avoiding the need for
`.mockImplementation()`
- **Biome linter compatibility**: The approach avoids
`.mockImplementation()` entirely, preventing biome from converting
`function` keywords back to arrow functions
### Files changed:
- `package.json`, `package-lock.json`: vitest version updates
- `test/app/config-tests.ts`: Refactored CompilerProps mocks with shared
cePropsImpl
- `test/app/main-tests.ts`: Refactored all constructor mocks
(CompilerFinder, FormattingService, CompileHandler, etc.)
## Test plan
- [x] All tests pass with `npm run test-min`
- [x] Linter passes with `npm run lint`
- [x] Type checking passes with `npm run ts-check`
- [x] Pre-commit hooks pass
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
<img width="1405" height="474" alt="Clojure in Compiler Explorer 2"
src="https://github.com/user-attachments/assets/76dfed9b-d0eb-4764-b371-9c6023088a50"
/>
With Macro Expansion:
<img width="1642" height="594" alt="image"
src="https://github.com/user-attachments/assets/8b511af9-3617-426e-868d-5a99e5db5756"
/>
TODO
- [x] Language configuration
- [x] Compile via wrapper
- Inject namespace if necessary to simplify minimal code sample
- Parse Unix style command line parameters into compiler bindings
- Place file in path according to namespace
- [x] Install some versions of Clojure [PR
here](https://github.com/compiler-explorer/infra/pull/1849)
- [x] Macroexpansion view (modeled on Rust macro expansion view)
- [x] Filter out command line options that would break wrapper operation
- [x] ~~Parse `--help` output to a list of options~~ Reverted because
not applicable.
- [x] Short form compiler options
- [x] Support Clojure compiler settings via env var, like
`JAVA_OPTS=-Dclojure.compiler.direct-linking=true
-Dclojure.compiler.elide-meta=[:doc,:file]`
NOT DOING
- [x] ~~Support loading dependencies~~ Non-trivial enhancement. Not
necessary for initial release.
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
## What
Adds [Revive's Resolc](https://github.com/paritytech/revive) compiler
for compiling Solidity and Yul (Solidity IR) to RISC-V and PolkaVM
assembly.
### Main Additions
- [x] Implement new `ResolcCompiler`
- [x] Implement Yul language definition and config for Monaco
- [x] Add Resolc as a compiler for the Solidity and Yul languages
- The `ResolcCompiler` handles both kinds of language input
- [x] Implement initial `PolkaVMAsmParser` (no source mappings)
- [x] Enable viewing LLVM IR in a supplementary view
- [x] Implement a new LLVM IR backend option for toggling between
optimized and unoptimized ll
- Affects non-resolc files ([see
commit](606bab9a59))
- Disabled by default
- (Enable by setting `this.compiler.supportsIrViewOptToggleOption =
true` in a compiler's constructor)
- The compiler's `getIrOutputFilename()` will receive the LLVM IR
backend options
### CE Infra
Accompanying CE Infra PR:
https://github.com/compiler-explorer/infra/pull/1855
## Overall Usage
### Steps
(See screenshots)
* Choose between two input languages:
* Solidity
* Yul (Solidity IR)
* Choose a Resolc compiler
* View assembly:
* PolkaVM assembly (if enabling "Compile to binary")
* RISC-V (64 bits) assembly
* View intermediate results:
* Optimized LLVM IR (if enabling "Show Optimized" in the LLVM IR view)
* Unoptimized LLVM IR
### Notes
Source mappings currently only exist between:
- Yul and RISC-V
- Yul and LLVM-IR
## Screenshots
<img width="1502" height="903" alt="CE Yul RISC-V LLVM IR"
src="https://github.com/user-attachments/assets/7503b9b5-0f2c-4ddf-9405-669e4bdcd02d"
/>
<img width="1502" height="903" alt="CE Solidity PolkaVM"
src="https://github.com/user-attachments/assets/eeb51c99-3eaa-4dda-b13c-ac7783e66cb8"
/>
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
