## 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
Fixes#8273
The default NASM output format was `elf` (32-bit ELF), causing a
spurious `64-bit unsigned relocation zero-extended from 32 bits
[-w+zext-reloc]` warning when using 64-bit addressing (which is the
common case on CE's x86-64 infrastructure).
Changed the default to `elf64`. Users who explicitly need 32-bit ELF
output can still pass `-felf` to override.
*(I'm Molty, an AI assistant acting on behalf of @mattgodbolt)*
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
*(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>
Today we only support passing options to the codegen backend, but not
the compiler that produces IL.
This change adds a new pseudo-option `-compopt`/`--compiler-options` so
that options follow after this pseudo-option can be passed to the
compiler that produces IL.
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
Adds support for [TinyGo](https://tinygo.org/), an LLVM-based Go
compiler targeting microcontrollers and WebAssembly.
## Changes
- **New `TinyGoCompiler` class** (`lib/compilers/tinygo.ts`): Extends
BaseCompiler with TinyGo-specific handling:
- Forces binary mode (TinyGo has no `-gcflags=-S` equivalent — it's
LLVM-based, not gc)
- Sets up `TINYGOROOT`, `GOROOT`, and `PATH` environment variables
- Uses `tinygo build -o <output>` as the compilation command
- User arguments (e.g. `-opt=2`, `-gc=none`, `-scheduler=none`) pass
through directly
- **Config**: Adds TinyGo 0.37.0 to `go.amazon.properties`
- **Registration**: Exports `TinyGoCompiler` from `_all.ts`
## Why TinyGo?
TinyGo produces significantly smaller binaries than standard Go (445KB
vs 1.5MB for a hello world). It targets a different niche —
microcontrollers, WASM, and resource-constrained environments — making
it an interesting comparison alongside the existing gc and gccgo
compilers.
## Testing
Tested locally with CE running on a non-default port:
- ✅ Compiler detected and version parsed correctly
- ✅ Compilation produces x86 assembly via objdump (5000+ lines for a
simple program)
- ✅ Execution works (`println` output captured correctly)
- ✅ User arguments like `-opt=2` pass through correctly
- ✅ All pre-commit checks pass (ts-check, lint, properties validation,
related tests)
## Infra
TinyGo 0.37.0 is already configured in the infra repo
(`bin/yaml/go.yaml`) — installation is just a tarball download from
GitHub releases.
The config references `/opt/compiler-explorer/golang-1.24.2/go` as
GOROOT — TinyGo needs a standard Go installation for the stdlib.
Closes#3969🤖 Generated by LLM (Claude, via OpenClaw)
---------
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>
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>
Go libraries on Conan use a `go_` prefix (e.g. `go_uuid`) but the frontend
was constructing annotation URLs without it. Add library-level `lookupname`
support in options-handler so versions inherit it, and set `lookupname` and
`packagedheaders` on Go libraries. Also suppress the "no include paths"
warning for `packagedheaders` libraries since their paths are resolved at
build time.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
## Summary
- Fixed `delayCleanupTemp: any` → `boolean`
- Fixed `toolchainPath: any` → `string | undefined`
- Changed `getToolchainPath()` to return `string | undefined` instead of
`string | false` (more idiomatic TypeScript)
- Fixed a latent bug in `changeOptionsBasedOnOverrides`
### Bug fix details
The bug was introduced in commit 079d49575 ("Compiler overrides #5001")
on May 16, 2023.
The original **correct** code (from commit 86a84f7f6) was:
```typescript
let sysrootPath: string | undefined;
const overriddenToolchainPath = this.getOverridenToolchainPath(overrides);
if (overriddenToolchainPath) {
sysrootPath = getSysrootByToolchainPath(overriddenToolchainPath);
}
```
The buggy refactor changed it to:
```typescript
const sysrootPath = overriddenToolchainPath ??
getSysrootByToolchainPath(overriddenToolchainPath);
```
This had two issues:
1. **The fallback was never reached**: `false ?? x` returns `false`
because `false` is not nullish (only `null`/`undefined` trigger `??`)
2. **The fallback passed the wrong variable**: It passed
`overriddenToolchainPath` to the fallback, but when the fallback is
needed, that variable would be `false`/`undefined`
Fixed to match the original correct behaviour:
```typescript
const sysrootPath = overriddenToolchainPath
? getSysrootByToolchainPath(overriddenToolchainPath)
: this.toolchainPath
? getSysrootByToolchainPath(this.toolchainPath)
: undefined;
```
The sysroot is now always computed via `getSysrootByToolchainPath()`,
since toolchain paths (e.g. `/opt/compiler-explorer/gcc-7.2.0`) differ
from sysroot paths (e.g.
`/opt/compiler-explorer/gcc-7.2.0/x86_64-pc-linux-gnu/sysroot`).
## Test plan
- [x] `npm run ts-check` passes
- [x] `npm run test-min` passes
- [x] Pre-commit hooks pass
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.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)
Most of these should be fairly noncontroversial but for the others I
figured clang-format is better than no formatter. If someone ends up
adding more "official" options then it should be straightforward to
switch to using that instead.
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
Improves types for two properties in BaseCompiler:
- `alwaysResetLdPath: any` → `boolean` (added `false` default to
`ceProps()` call)
- `compilerWrapper: any` → `string | undefined` (using generic
`compilerProps<string>()`)
These are more precise than the initial `PropertyValue` type, matching
their actual usage.
## Test plan
- [x] `npm run ts-check` passes
- [x] `npm run test-min` passes
- [x] Pre-commit hooks pass
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
## Summary
- `objdumperClass: any` → `new () => BaseObjdumper`
- `executionEnvironmentClass: any` → `typeof LocalExecutionEnvironment`
Used a constructor type for `objdumperClass` since `BaseObjdumper` is
abstract and `typeof BaseObjdumper` wouldn't allow instantiation.
### Additional fix
This change exposed a latent type issue: `ObjdumpResult.asm` is `string
| undefined`, but was being passed directly to
`postProcessObjdumpOutput(output: string)`. Added a nullish coalescing
fallback (`?? ''`) for safety.
## Test plan
- [x] `npm run ts-check` passes
- [x] `npm run test-min` passes
- [x] Pre-commit hooks pass
🤖 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
- Changes `ClientOptionsType.tools` from `Record<any, any>` to
`Record<LanguageKey, Record<string, Tool>>`
- This prevents bugs like the one fixed in #8406 where `tool.name` was
used instead of `tool.tool.name`
- The `any` type was escaping type checking entirely
## 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
- Minor/patch package updates (AWS SDK, Sentry, Biome, Vitest, etc.)
- Removes Biome version pin workaround (bug in 2.3.9 is fixed)
- Fixes for stricter Express types in `@types/express` - `req.params`
and `req.query` values are now correctly typed as `string | string[]`
## Test plan
- [x] `npm run ts-check` passes
- [x] `npm run lint` passes
- [x] `npm run test-min` passes
- [x] Manual testing of shortlinks, API endpoints, noscript mode
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude Opus 4.5 <noreply@anthropic.com>
This depends on https://github.com/compiler-explorer/infra/pull/1936
which builds the runtimes when installing the Carbon toolchain. Then
this PR passes `--prebuilt-runtimes` to the `carbon link` step in order
to use them. The result is that compiler explorer no longer times out
when trying to link a binary with the Carbon toolchain.
The carbon.ts file is refactored a little in an attempt to improve
clarity about what is going on, and some comments are added throughout.
Fixes https://github.com/carbon-language/carbon-lang/issues/6603.
Documents why buildenvsetup.props works with prediscovered compilers
(language-level properties) while externalparser needed a different
approach (group-level properties). References #7150 for long-term fix.
🤖 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).
Previously, wine initialization would never complete because it waits
for a magic string which cmd.exe never outputs, because the
corresponding echo never executes. This change adds a newline to the end
of the echo command, so the command executes, and wine initialization
completes.
Co-authored-by: Grant Moyer <code@grantmoyer.com>
in `dev-2025-02`, odin changed from single-module debug builds to
multi-module and prevents it from spitting out a single `.s` file. this
adds version checking to make sure that any odin version after
`dev-2025-02` uses `-use-single-module`. additionally, changes were made
around name canonicalization that required changing the matching for
label names to avoid clogging the assembly output (both standard and
binary)
