<img width="1405" height="474" alt="Clojure in Compiler Explorer 2"
src="https://github.com/user-attachments/assets/76dfed9b-d0eb-4764-b371-9c6023088a50"
/>
With Macro Expansion:
<img width="1642" height="594" alt="image"
src="https://github.com/user-attachments/assets/8b511af9-3617-426e-868d-5a99e5db5756"
/>
TODO
- [x] Language configuration
- [x] Compile via wrapper
- Inject namespace if necessary to simplify minimal code sample
- Parse Unix style command line parameters into compiler bindings
- Place file in path according to namespace
- [x] Install some versions of Clojure [PR
here](https://github.com/compiler-explorer/infra/pull/1849)
- [x] Macroexpansion view (modeled on Rust macro expansion view)
- [x] Filter out command line options that would break wrapper operation
- [x] ~~Parse `--help` output to a list of options~~ Reverted because
not applicable.
- [x] Short form compiler options
- [x] Support Clojure compiler settings via env var, like
`JAVA_OPTS=-Dclojure.compiler.direct-linking=true
-Dclojure.compiler.elide-meta=[:doc,:file]`
NOT DOING
- [x] ~~Support loading dependencies~~ Non-trivial enhancement. Not
necessary for initial release.
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
## What
Adds [Revive's Resolc](https://github.com/paritytech/revive) compiler
for compiling Solidity and Yul (Solidity IR) to RISC-V and PolkaVM
assembly.
### Main Additions
- [x] Implement new `ResolcCompiler`
- [x] Implement Yul language definition and config for Monaco
- [x] Add Resolc as a compiler for the Solidity and Yul languages
- The `ResolcCompiler` handles both kinds of language input
- [x] Implement initial `PolkaVMAsmParser` (no source mappings)
- [x] Enable viewing LLVM IR in a supplementary view
- [x] Implement a new LLVM IR backend option for toggling between
optimized and unoptimized ll
- Affects non-resolc files ([see
commit](606bab9a59))
- Disabled by default
- (Enable by setting `this.compiler.supportsIrViewOptToggleOption =
true` in a compiler's constructor)
- The compiler's `getIrOutputFilename()` will receive the LLVM IR
backend options
### CE Infra
Accompanying CE Infra PR:
https://github.com/compiler-explorer/infra/pull/1855
## Overall Usage
### Steps
(See screenshots)
* Choose between two input languages:
* Solidity
* Yul (Solidity IR)
* Choose a Resolc compiler
* View assembly:
* PolkaVM assembly (if enabling "Compile to binary")
* RISC-V (64 bits) assembly
* View intermediate results:
* Optimized LLVM IR (if enabling "Show Optimized" in the LLVM IR view)
* Unoptimized LLVM IR
### Notes
Source mappings currently only exist between:
- Yul and RISC-V
- Yul and LLVM-IR
## Screenshots
<img width="1502" height="903" alt="CE Yul RISC-V LLVM IR"
src="https://github.com/user-attachments/assets/7503b9b5-0f2c-4ddf-9405-669e4bdcd02d"
/>
<img width="1502" height="903" alt="CE Solidity PolkaVM"
src="https://github.com/user-attachments/assets/eeb51c99-3eaa-4dda-b13c-ac7783e66cb8"
/>
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
## Summary
Implements automated detection of potential duplicate issues using
GitHub Actions.
## Implementation Details
- Uses `wow-actions/potential-duplicates@v1` action
- Triggers on issue `opened` and `edited` events
- Configured with **90% similarity threshold** to minimize false
positives
- Automatically adds `potential-duplicate` label and comment with links
to similar issues
## Rationale for 90% Threshold
Based on manual testing with the `gh_tool` CLI:
- 85% threshold produced too many false positives from template-based
matches
- True duplicates typically have 90%+ similarity
- Uses Damerau-Levenshtein distance algorithm (same as manual tool)
## Testing
- ✅ YAML syntax validated
- ✅ Pre-commit hooks passed (lint + ts-check)
- ✅ Created `potential-duplicate` label in repository
- Manual testing of similar configuration showed good results at 90%
threshold
## Dependencies
- Depends on #8166 (add-gh-tools-cli branch) being merged first
- This PR adds the automation layer on top of the manual tooling
🤖 Generated with [Claude Code](https://claude.com/claude-code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
This PR adds a new Python CLI tool for automating GitHub repository
management tasks.
## Overview
The initial implementation provides duplicate issue detection using text
similarity analysis. This is the first step toward automating repository
triage tasks.
## Features
- **Click-based CLI** with subcommands for future extensibility
- **find-duplicates command** for detecting duplicate issues using text
similarity
- Uses **gh CLI** for GitHub API access (no token management needed)
- Text similarity using `difflib.SequenceMatcher` (ratio-based
algorithm)
- Configurable similarity threshold (default: 0.6)
- Progress bar for long-running comparisons
- Age filtering support (`--min-age` parameter)
- Standard Python src-layout with **uv** for dependency management
- **Comprehensive test suite** with pytest (integrated into CI)
## Project Structure
```
etc/scripts/gh_tool/
├── src/gh_tool/ # Main package
│ ├── cli.py # Click-based CLI interface
│ └── duplicate_finder.py # Core duplicate detection logic
├── tests/ # Test suite
│ └── test_duplicate_finder.py
├── docs/ # Documentation
│ ├── TRIAGE-CRITERIA.md # Triage guidelines from manual review
│ └── PHASE1-FINDINGS.md # Historical analysis of 855 issues
├── pyproject.toml # Package configuration
└── README.md # Usage documentation
```
## Usage
```bash
cd etc/scripts/gh_tool
uv sync
uv run gh_tool find-duplicates /tmp/report.md
```
**Options:**
- `--threshold FLOAT` - Similarity threshold 0-1 (default: 0.6)
- `--state {all,open,closed}` - Issue state to check (default: open)
- `--min-age DAYS` - Only check issues older than N days (default: 0)
- `--limit INTEGER` - Maximum number of issues to fetch (default: 1000)
- `--repo TEXT` - GitHub repository in owner/repo format (default:
compiler-explorer/compiler-explorer)
**Example:**
```bash
# Find high-confidence duplicates in open issues
uv run gh_tool find-duplicates /tmp/report.md --threshold 0.85
# Check all issues older than 30 days
uv run gh_tool find-duplicates /tmp/report.md --state all --min-age 30
```
## Testing
The tool includes comprehensive test coverage:
- Unit tests for similarity calculation
- Integration tests for duplicate detection
- Edge case handling (transitive grouping, age filtering, threshold
sensitivity)
- Report generation validation
**Run tests:**
```bash
cd etc/scripts/gh_tool
uv run pytest -v
```
Tests are integrated into CI and run on every push.
## Documentation
- **`README.md`**: Complete usage guide with examples
- **`docs/TRIAGE-CRITERIA.md`**: Comprehensive triage guidelines
developed during manual review of 22+ issues
- **`docs/PHASE1-FINDINGS.md`**: Historical analysis context from
initial 855 issue review
## CI Integration
The tool is integrated into the GitHub Actions workflow:
- `uv` is installed via `astral-sh/setup-uv@v6`
- Tests run automatically on every push
- Ensures tool remains functional as codebase evolves
## Next Steps
Future enhancements planned for follow-up PRs:
- GitHub Action for automatic duplicate detection on new issues
- Additional automation tools (upstream health checker, label validator,
etc.)
- Automated triage reports
## Changes in this PR
- ✅ Core duplicate detection implementation
- ✅ Comprehensive test suite (192 lines)
- ✅ CI integration
- ✅ Complete documentation
- ✅ Example triage criteria and findings
---------
Co-authored-by: Claude <noreply@anthropic.com>
Close#5530. Infra:
https://github.com/compiler-explorer/infra/pull/1711. Previous work by
@siboehm at #5531
## Summary
This pull request introduces support for the
[Triton](https://github.com/triton-lang/triton) language, a Python-based
DSL for writing highly efficient GPU kernels.
- [x] **New Language Support**: I've added comprehensive support for the
Triton programming language, allowing users to compile and inspect
Triton kernels within Compiler Explorer. (c.f.,
`lib/compilers/triton.ts`)
- [x] **Python Wrapper for Compilation**: A new Python wrapper script
(`triton_wrapper.py`) has been introduced to manage Triton compilation,
patching its behavior to dump compiled kernels and intermediate
representations without requiring actual execution, and consolidating
the output for Compiler Explorer.
- [x] **Device Assembly View**: Enables viewing of generated device
assembly code (e.g., PTX, AMDGCN) and various intermediate
representations (MLIR, LLVM IR) produced by the Triton compiler.
- [x] **MLIR Parsing**: New parsers (`asm-parser-mlir.ts` and
`mlir-pass-dump-parser.ts`) have been added to correctly interpret and
display MLIR assembly and optimization pass dumps, including source
location information.
- [x] **Multi-Version & Multi-Backend Support**: Painstakingly includes
all 8 versions (from 2.2.0 to 3.3.1) of Triton that supports Python
3.12. Supports both CUDA and HIP backend for Triton 3.
## Screenshots
Source and assembly:
<img width="1354" height="789" alt="image"
src="https://github.com/user-attachments/assets/c29650ff-2073-40e0-a9e6-ff8377094b5e"
/>
Device view for MLIR and LLVM IR:
<img width="1402" height="670" alt="image"
src="https://github.com/user-attachments/assets/43dd5c68-ca78-41b1-9865-e97ffe3ef73c"
/>
Opt pipeline viewer:
<img width="1408" height="668" alt="image"
src="https://github.com/user-attachments/assets/429eef8c-aaac-4781-aafa-39ef0ffc7241"
/>
Diff of TTIR in Triton 3.3.1 vs 2.3.0:
<img width="1580" height="726" alt="image"
src="https://github.com/user-attachments/assets/a928c893-dd9a-4c3a-a048-14046e56a14c"
/>
CUDA & HIP:
<img width="1596" height="800" alt="image"
src="https://github.com/user-attachments/assets/c18800c3-cfad-4e5e-96de-ba92c9f236ea"
/>
## Implementation Details (and Notes for Reviewers)
- For Device Assembly View, I Implemented `MlirAsmParser` for parsing
MLIR assembly. Technically MLIR is not an assembly language, but there
is no better choice to make the source line map work w/ device view.
- I Implemented `MlirPassDumpParser` for processing MLIR optimization
pass dumps. I tried to subclass `LlvmPassDumpParser`, but they turn out
to be too different to worth doing it.
- `LlvmPassDumpParser` made some assumptions that do not hold true for
MLIR passed. Some effort is put to make sure that the passes are
properly diff-ed, since some passes can run multiple times and also
sometimes pass can be nested (i.e., some number of `before`s followed by
some number of `after`s)
- A lot of effort is put into `patch_triton` to make sure that the we
only compile the kernel without actually running it, and that needs to
work across all the versions we support.
## Steps to Run Locally
1. Clone https://github.com/ShawnZhong/compiler-explorer-infra.git
2. Install Triton to `/opt/compiler-explorer/triton`:
```sh
$ cd compiler-explorer-infra
$ ./bin/ce_install install triton
$ ls /opt/compiler-explorer/triton
# v2.2.0 v2.3.0 v2.3.1 v3.0.0 v3.1.0 v3.2.0 v3.3.0 v3.3.1
```
3. Clone https://github.com/ShawnZhong/compiler-explorer.git and
checkout branch `triton`
4. Run Compiler Explorer
```sh
make EXTRA_ARGS='--language triton' dev
```
5. Enjoy
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
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 PR adds support for the Mojo programming language.
Explicitly tested viewing the generated assembly, LLVM IR, and running
the generated executable.
- Add initial support for Numba compilation: asm, demangling, execution
Numba wraps Python functions in `Dispatcher` objects. Each dispatcher
contains zero or more compiled argument-type-indexed overloads of its
function. We import the user's code as a module, and emit the code from
all overloads of all dispatchers that the module publicly exposes.
Name mangling is odd in Numba. It uses a similar mangling syntax to C++,
but also encodes non-symbol (`r"[^a-z0-9_]"`) characters as `_%02x`.
This encoding yields valid identifier names, so it is not strictly
invertible. Here, I have hard-coded some replacements to decode some
common cases at the cost of possible clashes with ugly user-defined
names.
Screenshot captured via `make dev EXTRA_ARGS="--debug --language numba"`
## To do
- [x] Answer questions of #5591.
- [x] Acquire a python environment.
- [ ] Automatically run the python test?
Locally, I have installed a virtual environment with python 3.12.3 with
```shell
path/to/python -m venv venv_numba
path/to/venv_numba/bin/python -m pip install numba==0.61.0 scipy>=0.16
```
and configured its use with
```properties
# compiler-explorer/etc/config/numba.local.properties
compilers=&numba
defaultCompiler=numba_0_61_0
group.numba.compilers=numba_0_61_0
group.numba.baseName=Numba
compiler.numba_0_61_0.exe=/path/to/python3.13
compiler.numba_0_61_0.semver=0.61.0
```
I run this python-side test file with
```python
path/to/venv_numba/bin/python -m unittest etc/scripts/test_numba_wrapper.py
```
---------
Co-authored-by: Mats Jun Larsen <mats@jun.codes>
There's nothing special with these anymore. They are the same both
locally and in CI now, because our Vitest and Biome setups don't behave
differently there
Details:
LFortran is a modern open-source (BSD licensed) interactive Fortran
compiler built on top of LLVM. See, https://lfortran.org for more
details.
There was an interest in the community to add the compiler into the
Compiler Explorer: https://github.com/lfortran/lfortran/issues/623.
So, this PR adds it.
LFortran is in alpha (the source code compiles to binary and execute.
But, users are expected that their code can break). It can emits AST,
ASR, LLVM, C, C++, WAT, Julia, Fortran, etc. It has multiple backend
like LLVM (default), C, C++, x86, WASM, fortran and mlir.
For more options run `--help`.
Changes in this PR:
- Add LFortran as a new Fortran compiler.
- `-g` options is enabled by default in `optionsForFilter`. Providing an
option
to disabling it helps other compilers (that doesn't have complete
support for
debug information) to compile successfully
for https://github.com/compiler-explorer/compiler-explorer/issues/2331
Hey, so I am currently trying to improve the SPIR-V ecosystem, in-charge
of the [SPIR-V Guide](https://github.com/KhronosGroup/SPIRV-Guide), and
part of the SPIR-V Working Group. We talked at our last Face-2-Face
gathering about getting more support for GPU tooling in something like
Compiler Explorer because you have all made this such an amazing tool!
I have enjoyed working in this codebase and happy to help keep improving
the SPIR-V as people find issues or want enhancements (I was already
about to spend time rebuilding Compiler Explorer, so happy to donate my
time to a single tool's effort)
(For those who haven't spent last few years staring at SPIR-V)
- SPIR-V is a an IR (very much like LLVM IR) but for GPUs
- SPIR-V can be used for Graphics and Compute
- Compute:
- Can be tied to things like clang, llvm, mlir, OpenCL, etc
- One could take `spirv` as a language and compile it to something like
x86
- (Future PRs for this realm of things)
- Graphics:
- Much harder to actually "compile" to any ISA because other graphics
pipeline information is missing that will effect the final ISA
- Microsoft has even now planned to move to [SPIR-V for DirectX
soon](https://devblogs.microsoft.com/directx/directx-adopting-spir-v/)
- Both:
- There are many tools that run on SPIR-V regardless (hence why they
share the same IR)
- Being able to do tooling in compiler explorer would be AMAZING
This PR adds `SPIR-V` as a language and a new `SPIRV-Tools` compiler as
an initial compiler for it the language (since we already have the
SPIRV-Tools repo being pulled in on the infra side!)
I personally use `spirv-opt` and `spirv-val` the most and have been
testing this locally for a few days and feel it is ready to go. I plan
to slowly add more tools (ex. `spirv-fuzz`, `spirv-cross`,
`spirv-reflect`, etc)
Cheers!
(some screenshots of course)
Pythran is a python to c++ transpiler.
Our supports both the C++ and the full link to a share library (a python
module).
See https://pypi.org/project/pythran/ for more information.
fixes#6079
Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
[](https://renovatebot.com)
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
|
[peter-evans/create-pull-request](https://togithub.com/peter-evans/create-pull-request)
| action | major | `v5` -> `v6` |
---
### Release Notes
<details>
<summary>peter-evans/create-pull-request
(peter-evans/create-pull-request)</summary>
###
[`v6`](https://togithub.com/peter-evans/create-pull-request/compare/v5...v6)
[Compare
Source](https://togithub.com/peter-evans/create-pull-request/compare/v5...v6)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 8pm on monday" in timezone
America/Chicago, Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Mend
Renovate](https://www.mend.io/free-developer-tools/renovate/). View
repository job log
[here](https://developer.mend.io/github/compiler-explorer/compiler-explorer).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yMDAuMCIsInVwZGF0ZWRJblZlciI6IjM3LjIwMC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
[](https://renovatebot.com)
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [github/codeql-action](https://togithub.com/github/codeql-action) |
action | major | `v2` -> `v3` |
---
### Release Notes
<details>
<summary>github/codeql-action (github/codeql-action)</summary>
### [`v3`](https://togithub.com/github/codeql-action/compare/v2...v3)
[Compare
Source](https://togithub.com/github/codeql-action/compare/v2...v3)
</details>
---
### Configuration
📅 **Schedule**: Branch creation - "before 8pm on monday" in timezone
America/Chicago, Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about this update
again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
This PR has been generated by [Mend
Renovate](https://www.mend.io/free-developer-tools/renovate/). View
repository job log
[here](https://developer.mend.io/github/compiler-explorer/compiler-explorer).
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yMDAuMCIsInVwZGF0ZWRJblZlciI6IjM3LjIwMC4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9-->
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Add support for the Spice programming language.
Spice (`spicelang`) is a simple, AOT compiled, LLVM-based systems
language with focus on practicality and performance.
**Key features of Spice**
- simplicity - see what you get aproach with batteries included
- performance: As Spice uses LLVM as its primary backbone, it competes
with the performance of other LLVM-based compilers
- enhanced safety: Spice implements an enhanced safety mechanism, which
includes builtin heap type with auto-free and more
- cross-compile support: Currently x86_64, AArch64 and wasm32 are
supported cross-compilation targets, but more to come
- Pretty good C and C++ interop
**Links**
- Source code: https://github.com/spicelang/spice
- Website: https://spicelang.com
- Playground (own CE instance): https://play.spicelang.com
- Infra PR: https://github.com/compiler-explorer/infra/pull/1229
**Things this PR addresses**
- General support for Spice
- Three code examples
- Spice mode (Syntax highlighting)
- Opt pipeline support
- LLVM mca and osaca support
