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)
The existing heuristics don’t reliably recognise LLVM IR produced by
`rustc` (e. g. when the generated code does not use any LLVM
intrinsics), so this adds LLVM IR detection based on the
`--emit=llvm-ir` and `--emit llvm-ir` command line flags.
The same race condition that was reported in #7012 also affects the opt
pipeline view.
I couldn’t reproduce the race condition locally, but on the live site it
happens relatively often, e. g. in https://godbolt.org/z/4Y1qfvTvz.
- Made parsers stateful instances instead of shared static state (for
mllvm options). Fixes#8011 as this is caused by multiple clang-based
compilers being run concurrently and stomping over each others' state.
- passes `Compiler` to the constructor, which removes some param passing
- Added some missing awaits
- Tried to get things less dependent on `examples`, only `go` needs it
- Spotted that `zig` c++ might have issues in discovery
- Fly-by fixed a broken go path in ppc64le_gl122
- removed a redundant override in coccinelle
- made the mojo parser actually use the parser it defined
- canonified tablegen's special method
-
I changed the zig parser too but as best I can tell it was broken before
(the `1` return value from the command it runs:)
```
ubuntu@ip-172-30-0-164:/infra/.deploy$ /opt/compiler-explorer/zig-0.14.1/zig c++ -mllvm --help-list-hidden /infra/.deploy/examples/c++/default.cpp -S -o /tmp/output.s
...
--x86-use-vzeroupper - Minimize AVX to SSE transition penalty
--xcore-max-threads=<number> - Maximum number of threads (for emulation thread-local storage)
/infra/.deploy/examples/c++/default.cpp:1:1: error: FileNotFound
```
return code 1 (means it's not cached)
---------
Co-authored-by: Partouf <partouf@gmail.com>
<!-- 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!
-->
Co-authored-by: Ofek Shilon <oshilon@speedata.io>
Fix#7809 and then some:
Stop processing opt-remarks if none were requested,
Make gcc dump remarks to file,
separate opt-file handling to ClangCompiler and GccCompiler,
make DefaultCompiler inherit GccCompiler,
move some tests around.
This is mainly for `pahole`, which requires type information that is
only present with `-C debuginfo=2`:
https://doc.rust-lang.org/rustc/codegen-options/index.html#debuginfo
CE originally passed `-g` to `rustc` (which is an alias for `-C
debuginfo=2`), but this was changed in
c4411ff2a1 to `-C debuginfo=1` to work
around https://github.com/rust-lang/rust/issues/11906. However, this
workaround never actually removed frame pointers, so switching back to
`-C debuginfo=2` should not affect codegen for very old `rustc`
versions. See also #79.
Rust compilers output to fixed-named intermediate files. When running a
regular compiler with `--emit-llvm` _and_ an IR view on the same source,
the outputs fight.
This ensures the intermediate files for IR are named differently.
Thanks @bjorn3
Closes#7012
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.
Following #6439: mark the go compiler `gc` as not supporting cfg.
Also, don't pass argument to `isCfgCompiler` - the base-compiler
implementation uses `this.compiler.instructionSet` anyway.
Demangled Rust identifiers under the `legacy` name mangling scheme rely
on a hash to disambiguate items with the same name, such as different
monomorphisations of the same function or different closures’
`call_once` methods.
In the `v0` mangling scheme, this is no longer a problem. However,
configuring the demangler to show hashes in `legacy` names will include
crate-id hashes in `v0` names, which are [mostly
unneeded](https://rust-lang.github.io/rfcs/2603-rust-symbol-name-mangling-v0.html#appendix-a---suggested-demangling).
This PR introduces a new checkbox *Options...* → *Verbose demangling*
that lets the user select if they want to include disambiguating hashes
in demangled identifiers.
This checkbox is only shown for compilers that support verbose
demangling, and deactivated when the *Demangle identifiers* checkbox is
unchecked.
Resolves#1754.
Resolves#6255.
All compilations run asynchronously under `await Promise.all` in
`BaseCompiler.doCompilation`:
f3277b8aed/lib/base-compiler.ts (L2256-L2263)
ASM and MIR processing is done from the main `runCompiler` and IR from
the auxiliary `generateIR`. But both compilation calls are passed the
same `options` - which include `--emit asm` for generation of `output.s`
assembly file and `--emit mir=...` for generation of MIR file. So these
2 identically-named file pairs are generated *and cleaned up* in both of
the parallel compilations, sometimes one compilation cleans up its
output before the other one tries to process its own, and mayhem ensues.
This PR makes rust's `generateIR` indeed generate *just* IR by filtering
switches.
From a design perspective: ideally CE would be more opinionated on which
outputs are generated on the main compilation and which on auxiliary
ones. I see no reason for MIR to be generated by an additional switch on
the main compilation and IR require a different compilation (there's
also something called `generateRustHir` - I don't know what it does and
am slightly afraid to ask).
I *think* most (all?) asm/IR outputs could be generated in a single main
compilation, and just post-processed for the different panes in parallel
- which could spell very good news also for servers load. But I don't
dare say anything categorical about *all* languages, compilers and
output (probably no one does). Would be happy to hear opinions.
(Anyway that's just for sake of discussion, this PR does nothing fancy
of that sort)
This adds a Racket optimisation pipeline view by reusing the existing
LLVM-focused optimisation pipeline UI. A Racket-specific pass parser
translates its output into passes for the UI to present.
This new Racket optimisation pipeline view is currently only enabled for
Racket nightly, as it depends on [recent
changes](https://github.com/racket/racket/pull/4842) to Racket's
compiler output to function.
This also extends the opt pipeline view to allow customising the
function selector label as well as the options and filters for each
compiler where needed.
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
This prepares for future work that will reuse the opt pipeline view
outside of the LLVM ecosystem by renaming related components to remove
the LLVM prefix.
The pass dumper keep its LLVM prefix, as it is assumed this part is
likely to be customised for each compiler ecosystem.
The historical component name has been preserved in the component list
as an alias to keep old links working.
For now, this removes all `llvm.dbg.*` calls from LLVM IR. This is
useful to keep coloring the line correspondence between source and IR,
while not polluting the IR with the debug intrinsics.
Admittedly, I don't have much of a clue of what's going on here, so I
might be missing obvious adaptions (e.g. can we disable this for all
non-LLVM compilers for now somehow?).
Also, not really a Node.JS testing wizard either... 🤷🏼
Just wanted this really bad for a workshop that's coming up soon ^^
Only tested with my system's default `clang` for now.
Fixes#5044
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
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.
The type which probably started as a real enum of possible post filtering
options now also includes options used for compilers' invocations.
The type was already split, but the naming was not reflecting this in the other
part of the code.
This changes tries to apply a simple renaming to the type only (corresponding
variables are left as 'filters').
While doing so, some typing error were discovered around the GccDump feature.
A fix for this will follow in a different PR.
Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
* WIP
* Type changes to the property getter
* Finish getting types working for properties.ts
* Reduce type casts in exec.ts
* Format files
* Remove old comment
Co-authored-by: Matt Godbolt <matt@godbolt.org>
