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).
* Minor updates only
* Added explicit radix parameter (10) to all Number.parseInt() calls throughout the codebase (new lint rule)
* Updated several @ts-ignore comments to @ts-expect-error for better TypeScript practices (new lint rule)
* Removed unnecessary @ts-ignore comments in some mode files (ditto)
* Used "none return" based arrow functions for some map stuff
* Replaced a `map()` call that didn't return anything to a for() loop
* Fixed up some cypress stuff, noting work for the future
- latest biome, and fix its configuration
- fixes "static" content to be globally configured too (instead of
per-line)
- fixes issues:
- imports fixed up
- `Date.now()` vs `+new Date()`
- some unused things `_` prefixed
After discussion with the team, turned off the unused parameter warning.
## Summary
Fixes unsafe type casting in assembly processing tools that was causing
`TypeError: text.split is not a function` runtime crashes.
## Root Cause Analysis
**COMPILER-EXPLORER-C2N** (57 occurrences) and **COMPILER-EXPLORER-AWW**
(184 occurrences):
The issue stemmed from tools making unsafe assumptions about
`compilationInfo.asm` type:
```typescript
// CompilationInfo.asm type (from types/compilation/compilation.interfaces.ts:168)
asm?: ParsedAsmResultLine[] | string; // "Temp hack until we get all code to agree on type of asm"
```
**The bug sequence:**
1. `base-compiler.ts:3120` converts string assembly to parsed format:
`result.asm = [{text: result.asm}]`
2. Tools unsafely cast back to string: `compilationInfo.asm as string`
3. `AsmParser.processBinaryAsm()` calls `splitLines(asmResult)`
4. If `asm` is actually `ParsedAsmResultLine[]`, `splitLines()` receives
an array
5. `text.split()` fails because arrays don't have `.split()` method
**Affected tools:** osaca-tool, x86to6502-tool, llvm-mca-tool
## Changes
### New Helper Functions in `utils.ts`:
1. **`extractTextLines(asm: string | any[]): string[]`**
- Safely extracts text lines from union types
- Throws descriptive errors for unexpected types (will surface in
Sentry)
2. **`normalizeAsmToString(asm: string | any[] | undefined): string`**
- Centralizes the common pattern of converting union type to string for
parser consumption
- Handles undefined gracefully
### Tool Fixes:
- **Removed unsafe casts**: `compilationInfo.asm as string` →
`normalizeAsmToString(compilationInfo.asm)`
- **Added null checks**: Explicit error handling for missing assembly
data
- **Type safety**: No more runtime type assumptions
## Impact
- Eliminates root cause of `text.split is not a function` errors (241+
occurrences combined)
- Maintains existing functionality - tools continue to work normally
- Better error messages when assembly data is missing
- Centralizes type handling logic for future maintainability
**Note:** The underlying architectural issue (union type "temp hack")
remains, but tools now handle it safely without crashes.
Fixes COMPILER-EXPLORER-C2N
Fixes COMPILER-EXPLORER-AWW
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Mats Jun Larsen <mats@jun.codes>
- Updates a number of uses of `fs-extra` which were only for the
promisified fs calls.
- Makes a few sync calls async.
- Makes a few `read` calls that didn't specify a text mode, but then
parsed as a string...into the equivalent `readFile` call.
- Don't mutate the `args` in-place which exposes the `-o0` of the stdbuf
args to the rest of the code (breaking a bunch of things)
- Check the return code of the LLVM parser dump and error if it's a
problem.
Found looking into #7410 but doesn't fix it
Rust error message locations (` --> <source>:<line>:<col>`) can have
more than one leading space, e. g. when the source code snippet that is
shown has line numbers greater than ten.
In this example (https://godbolt.org/z/9W8xPv36c), the error message is
not be recognised as an error and there are no red squigglies in the
editor pane.
When passing `-fdiagnostics-urls=always`/`-Z terminal-urls=yes`, the
hyperlink escape sequence was not stripped from the mouse hover widget
in the editor pane.
Link: https://godbolt.org/z/3cP8jj8jc
Hover over the empty braces in the C++ editor or the `i32` in the Rust
editor:
Before:
```
warning: no return statement in function returning non-void []8;;https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Warning-Options.html#index-Wno-return-type-Wreturn-type]8;;]x86-64 gcc 14.2 #1
error[]8;;https://doc.rust-lang.org/error_codes/E0308.htmlE0308]8;;]: mismatched typesrustc nightly #2
```
Now:
```
warning: no return statement in function returning non-void [-Wreturn-type]x86-64 gcc 14.2 #1
error[E0308]: mismatched typesrustc nightly #2
```
- Uses strings across the board in the UI part (no functional change
here from before; all state is the same as it was before).
- Sends _arrays_ in the POST, using the same `splitArguments` code as
the backend.
- Backend _still supports_ strings (though doesn't advertise), also
using same `splitArguments`.
- Moves `splitArguments` into common utils, and rephrases to avoid
unnecessary use of underscore and ES2021+ code.
Tested locally:
- with both old and new client code (ran new backend and old webcode to
show sending strings still works)
- with creating and removing tool windows (checked with `ldd` locally)
- with various strings on the client `moo foo "this is bad" #moo` and
even "error" things like `this is "badger` (with a missing close quote).
All works as you'd expect
Happy to break the "move the splitArguments" code into a separate PR if
that'd be easier to review separately.
Fixes#7195
Still mostly mindless numb work, one rename that touched many files
(`getArgumentParser` -> `getArgumentParserCls`), and a few real
improvements.
The goal is to be able to turn on `noImplicitAny` for the project, to
enforce higher code quality. 600 violations to go.
Fix#5951Fix#5085
Extended the fictitious version number for non-numbers, so that trunk
can be listed higher than a `yyyymmdd` as a version (EVE uses this)
Tiny change to regexes parsing compiler stdout lines, to make them stop
classifying lines like "(0.00 s) Setup: DONE" as errors.
One could imagine other, more thorough, fixes to [this
code](ec8f8e5d50/lib/utils.ts (L195-L202))
- it currently attempts to capture errors from all compilers, *not*
differentiating by compiler but instead by some general output formats
(`<source>`:line:col , or "file.ext":line, etc.). I settled for a 1-char
fix that seems to makes sense by itself.
Makes the Compiler Explorer app, and all the tooling ESM compatible.
Things that have been done:
1. The package.json has `type: module` now
2. All relative imports have a .js ending
3. All directory imports are now directory/index.js to comply with ESM
standards
4. Dependency node-graceful is now imported into tree, because the
package is broken under esm
5. Dependency p-queue has been bumped to 7.x with ESM support
6. Dependency profanities has been bumped to 3.x with ESM support
7. Webpack config is now both ESM and CommonJS compatible
8. Non-ESM compatible imports have been rewritten
9. ESLint configuration has been tweaked to not fail on .js imports
10. Mocha is now hacked together and ran with ts-node-esm
11. Webpack is now hacked together and ran with ts-node-esm
12. Webpack config is now ESM compatible, so that it can be used in the
dev server
13. Cypress code still runs commonjs, and has been excluded from the
tsconfig
14. All sinon mock tests have been commented out, because sinon module
mocks do not work with ESModules (because ESModules are immutable)
A lot of tests are now giving warnings/errors to stdout, yet still pass.
Docenizer codegenerator scripts have been updated, but I did not re-run
them, and instead just changed their code.
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
- latest sentry, tar-stream, which, some yamljs versions
- latest eslint-* stuff
- latest webpack manifest
- Applies all the automatic fixes for newer lint rules
- Bump the webpack version
applies new tslint stuff
* All semver comparisons now ensure it's safe to do so
* Oops, use correct class
* Remove leftover import
* Leave the Zig fixes for another PR
* Fix linter
* Fix test issues
* Make linter happy, yet again
* What?
* Address PR review
