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).
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
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)
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>
