* 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
This PR fixes the "unassigned file number" error in llvm-mca when
processing GCC-generated assembly with debug information #6795 .
**Problem**: GCC with `-g` flag generates `.loc` and `.file` debug
directives that cause llvm-mca to fail with "unassigned file number"
errors.
**Solution**: Filter out `.loc` and `.file` directives during assembly
preprocessing, similar to how other problematic directives are already
handled.
**Changes**:
- Add regex filtering for `.loc` and `.file` directives in
`rewriteAsm()`
- Make `rewriteAsm()` method public for testability
- Add comprehensive test coverage for debug directive removal
The fix is minimal, targeted, and follows the existing pattern of
directive filtering.
- 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>
"Bronto Refactor" is a tool that reads annotations in C++ source code
and generates edits based on those annotations. For CE specifically, it
outputs a copy of the primary file with the modifications applied.
Documentation can be found
[here](https://github.com/brontosource/bronto/blob/main/include/bronto/bronto.hpp)
and will also be made available at http://brontosource.dev in a nicer
format before this PR is merged.
I've attached a screenshot which hopefully conveys the idea.
One question I have is about how to actually deliver the tool. It is not
publicly available, but we do want folks to be able to play around with
it. We're happy to have you build it from source or we can deliver a
prebuilt binary, whatever is preferable.
This is my first time contributing here. I think I've got everything set
up appropriately (including sibling PR
https://github.com/compiler-explorer/infra/pull/1569 to the infra
repository) but please let me know if I'm missing anything.
<img width="1723" alt="BrontoRefactorToolScreenshot"
src="https://github.com/user-attachments/assets/cd605358-b7f2-49e8-9845-b6f3056fa4ef"
/>
Updated OSACA to version 0.7.0 that finally includes support for Intel
syntax assembly.
Therefore, I increased the version numbers in the `*.amazon.properties`
files and removed the check and error message for Intel syntax in
`osaca-tool.ts`.
Successfully tested with `make check` and manually with a local instance
Remove most, if not all, of the synchronous file reads. Hopefully this
will help a little with performance and "event loop lag". Mostly, it's
"try not to use third party packages when builtins now do the work".
Local testing seems OK - but needs a good poke around on staging to
exercise all the paths.
- 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.
- 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
This includes among others:
- Proper tsification of various tools code,
- Elimination of the `CompilationInfo2` type,
- Use of `CompilationInfo` instead of `Record<any, any>` in some places
- These lines in CompilationResult:
```
// Temp hack until we get all code to agree on type of asm
asm?: ResultLine[] | string;
```
The next task would be to get all code to agree on the type of
CompilationResult.asm, thereby enabling fixing of most the remaining
TSification.
This patch fixes a few issues with argument passthrough that have been
discovered since #6682 was landed.
* X86 didn't work if -march=CPU was supplied.
* It wasn't possible to override flags on MCA, because the auto-detected
flags came before user flags.
* Since compiler-explorer runs on x86 native hardware, if targetting
aarch64, it would result in an error about the default requested
native CPU not being available for the architecture.
X86 clang uses -march to specify the CPU, and it's invalid to supply
-march=<cpu> to LLVM-MCA. Meanwhile, LLVM-MCA requires an -mcpu
argument.
Therefore, to handle x86 it's necessary to rewrite -march to -mcpu so
long as the march flag is used to supply a CPU value (i.e. not an
architecture level beginning with `x86-64`).
Per https://maskray.me/blog/2022-08-28-march-mcpu-mtune, I understand
x86 is currently the only target to have this behaviour so it needs
special casing.
Additionally, llvm-mca assumes -mcpu=native if it is not otherwise
specified. Since compiler-explorer runs on x86 hardware, it is easy to
end up in a situation for example targetting aarch64 but with -mcpu=<an
x86 CPU>. To handle this case some logic is added to detect if a CPU is
not specified and the target is not x86, in which case -mcpu=generic is
supplied instead as a reasonable default for the target.
Further, handle the case where --target is being passed to the compiler,
and pass this through as -mtriple.
Testing:
* I have been testing on an aarch64-native machine.
* I have tested targeting x86 by specifying --target and using the
override functionality in compiler explorrer to specify x86.
* I have been inspecting the `--debug` output to see what flags are
passed to LLVM-MCA.
* I've checked that I can override the -mcpu in MCA regardless of what
is passed to the compiler.
* I have checked that I can supply either -march=x86-64* or -march=<cpu>
on the x86 target and things behave as expected.
Fixes: #6709
Currently if an MCA instance is constructed on a compiler, MCA runs with
the default target for the host it is running on.
Make it respect the target architecture by passing an -mtarget to MCA
conditioned on the detected instructionSet of the compiler.
Additionally, pass through any -mcpu, -march or -mtriple specified to
the compiler.
Mindless replacements of the form
`_.filter(options, option =>...` --> `options.filter(option =>...`.
One not *entirely* mindless replacement at the bottom of
compiler-dropin-tool.ts :
```
- return _.filter(pathFilteredFlags) as string[];
+ return pathFilteredFlags.filter(Boolean) as string[];
```
6 files can now stop importing underscore.
https://llvm.org/docs/CommandGuide/llvm-dwarfdump.html
This dumps the DWARF debugging information in a human readable form:
```
<source>: file format ELF64-x86-64
.debug_info contents:
0x00000000: Compile Unit: length = 0x00000063 version = 0x0004 abbr_offset = ...
0x0000000b: DW_TAG_compile_unit
DW_AT_producer ("GNU C17 9.4.0 ...)
```
This tool would be useful to have when comparing the debug output of two
compiler versions or compiler targets. For instance I wanted to find out
recently how AArch64 and X86 targets represent TLS variables.
The tool runs on the compiled binary, so is post compilation. If the
binary
has no debug information the tool does not crash, it just tells you that
there is no information.
To fit the other llvm/clang tools, I've just added an "llvm-dwarfdump
(trunk)"
like llvm-mca has done. Added it to c/c++/objc/objc++ (open CL can't
compile
to binary so skipped those). MSVC is excluded because it produces PDB
files
instead.
The tool works for at least ELF and XCOFF files, I haven't been able to
test
any others.
Small fixes for the Sonar analyzer.
* Support the C language
* Fix the argument passing. This one is not really relevant for users but useful for us if we need to debug a crash someday.
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>
This PR turns comma-dangle and indent eslint rules on for lib/. These
are rules inherited from the eslint config for static/, this PR just
makes things more consistent. Also turned
@typescript-eslint/no-var-requires back on while I was here.
<!-- 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!
-->