## 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>
- Removes `rootDirs` so all imports will be relative in the frontend
- Updates (and unifies) imports to be `../types/...` etc instead of
relying on "types" being in the rootDir for the frontend.
- Fixes one type that was being picked up from `lib` in the frontend.
- Adds a precommit hook to check in future
Paves the way to writing _unit_ tests for the frontend for the subset of
the frontend code we can import from `node` (which might be a lot of
it!)
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 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!
-->
Make MonacoPane calls `createDecorationsCollection` in a single place
instead of forcing many subclasses to remember to call
`initDecorations`. Some subclasses never use DecorationsCollection and
call init for no reason now, but it still seems healthier - this avoids
the possibility of a MonacoPane subclass trying to use an uninitialized
decoration collection.
Also remove the depracated `deltaDecorations` from stack-usage-view.
Compilers like to encode short-ish strings into immediate arguments to
various assembly instructions. This makes it hard to read the assembly.
To improve readability, show a string representation of a number’s bytes
when they’re valid UTF-8.
This now also shows a string representation for *unprintable* ASCII
characters, such as `10` being shown as `"\n"` or `1` as `"\u0001"`.
Resolves#6220.
## Examples
([link](https://godbolt.org/z/7hzn6b8YG))
* 8583909746840200552: `8'583'909'746'840'200'552 =
0x7720'2C6F'6C6C'6568 = 6.5188685003648344e+265 = "hello, w"`
* 1684828783: `1'684'828'783 = 0x646C'726F = 1.74467096e+22f = "orld"`
* -6934491452449512253: `-6'934'491'452'449'512'253 =
0x9FC3'BCC3'B6C3'A4C3 = -1.1500622354593239e-155 = "äöüß"`
* 1633837924: `1'633'837'924 = 0x6162'6364 = 2.61007876e+20f = "dcba"`
* 97: `97 = 0x61 = 1.35925951e-43f = "a"`
* 10: `10 = 0xA = 1.40129846e-44f = "\n"`
* 92: `92 = 0x5C = 1.28919459e-43f = "\\"`
## Open questions
* The code assumes little-endian encoding, so the string representation
is reversed compared to the numeric representation (see `integer`
example). Should this be configurable or should the bytes not be
reversed?
* Negative numbers are masked to 64-bit unsigned ints (same as in the
hex representation), so if the number is shorter than 8 bytes, it has
some leading `ff` bytes and is not valid UTF-8 (see
`small_negative_number` in the example link). Is this an acceptable
limitation?
* I'd like to add some tests for `getNumericToolTip`, but I’m not really
familiar with TypeScript. I tried to importing
`static/panes/compiler.ts` in a test file, but
([after](https://github.com/vitest-dev/vitest/discussions/1806#discussioncomment-3570047)
some [struggling](https://vitest.dev/config/#environment)) it seems that
that file needs a [specific DOM
element](3c26c64ca3/static/options.ts (L27))
that is not present during testing. The simplest solution I could come
up with is moving `getNumericToolTip` into another file (such as
`static/utils.ts`). Is that okay or is is it possible test
`static/panes/compiler.ts` some other way?
---------
Co-authored-by: Patrick Quist <partouf@gmail.com>
Replace the deprecated `monaco.editor.ICodeEditor.deltaDecorations` with `monaco.editor.IEditorDecorationsCollection`
Seems that today the official way of colouring monaco editors is having
them `createDecorationsCollection`, keep the resulting
decorations-collection and call `set` on it with new decorations
whenever needed.
There are many possible design choices on where to put it, I opted to
put `editorDecorations` in `MonacoPane`, and have
`MonacoPane.createEditor` initialize it only in panes where decorations
are actually used.
Also some signatures changed which had a broad (but non-interesting)
impact.
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>
* make nvcc show the device asm view button, stop after compiling host assembly
* keep and extract ptx device code
* paper over some typescript compile errors (maybe mitigating orchidjs/tom-select#500, orchidjs/tom-select#501)
* await on promise-returning methods
* use gcc objdump for nvcc host code, add nvdisasm to disassemble SASS .cubin
* append device ASM lines to result ASM so they're also colourized
* append device ASM to all ASM
* automatically open the device pane if the compiler supports emitting device ASM
* save device view open boolean in compiler state
* make the nvcc compiler return all PTX and SASS results as separate devices
* ensure line hover highlights propagate from editor to compiler panes, and are re-applied when the user changes the selected device
* update cuda properties
* Fix Editor not being able to load full links
* Better type for this.filename in compiler.ts
* Updates editor.ts and improves compilation types
* Fix some of the type issues, lots still remain
* fixes to language selection & refactoring of hub and some inits
* fix flow of events
* Fix llvm opt handling (cc @jeremy-rifkin)
Co-authored-by: partouf <partouf@gmail.com>
Co-authored-by: Matt Godbolt <matt@godbolt.org>
