## Summary
Fixes issue #7684 where dropdown menus displayed two arrows instead of
one, particularly visible in light theme.
## Root Cause
The double arrows were caused by conflicts between:
1. **TomSelect's Bootstrap 5 theme** - provides automatic dropdown
arrows via `background-image`
2. **Custom legacy CSS** - was adding duplicate arrows using `::after`
pseudo-elements
3. **Bootstrap 4 leftovers** - manual `<b class="caret">` elements in
templates
## Changes
- **Removed conflicting custom TomSelect arrow CSS** from
`explorer.scss`
- **Removed leftover `#[b.caret]` element** from font-size dropdown
template
- **Fixed theme background properties** - changed `background` to
`background-color` to preserve TomSelect's arrow images
- **Added reusable SCSS function** `dropdown-arrow-svg()` for generating
themed dropdown arrows
- **Updated dark themes** to override arrow colors using TomSelect's
exact CSS selector for precision
## Test Plan
- [x] Verify all dropdown menus show only one arrow in default/light
theme
- [x] Test dropdown arrows are visible and correctly colored in all
themes:
- [x] Default theme: dark gray arrow
- [x] Pink theme: dark gray arrow
- [x] Dark theme: light gray arrow
- [x] One-dark theme: medium gray arrow
- [x] Confirm dropdown functionality works correctly across all themes
- [x] Check that font-size dropdown works properly without manual caret
element
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
This PR adds support for the Mojo programming language.
Explicitly tested viewing the generated assembly, LLVM IR, and running
the generated executable.
This PR completes the migration from Bootstrap 4 to Bootstrap 5.3.5
following the plan outlined in
[docs/Bootstrap5Migration.md](https://github.com/compiler-explorer/compiler-explorer/blob/mg/bootstrap5/docs/Bootstrap5Migration.md).
## Migration Process
We followed a phased approach as documented in the migration plan:
1. **Phase 1: Dependency Updates and Basic Setup**
- Updated Bootstrap from 4.6.2 to 5.3.5
- Added @popperjs/core dependency (replacing Popper.js)
- Updated Tom Select theme from bootstrap4 to bootstrap5
2. **Phase 2: Global CSS Class Migration**
- Updated directional utility classes (ml/mr → ms/me)
- Updated floating utility classes (float-left/right → float-start/end)
- Updated text alignment classes (text-left/right → text-start/end)
3. **Phase 3: HTML Attribute Updates**
- Updated data attributes to use Bootstrap 5 prefixes (data-bs-toggle,
data-bs-target, etc.)
- Fixed tab navigation issues
4. **Phase 4: JavaScript API Compatibility Layer**
- Created bootstrap-utils.ts compatibility layer
- Updated component initialization for modals, dropdowns, popovers, etc.
5. **Phase 5: Component Migration**
- Updated and tested specific components (modals, dropdowns, toasts,
etc.)
- Fixed styling issues in cards and button groups
6. **Phase 6: Form System Updates**
- Updated form control classes to Bootstrap 5 standards
- Updated checkbox/radio markup patterns
- Simplified input groups
7. **Phase 7: Navbar Structure Updates**
- Updated navbar structure with container-fluid
- Fixed responsive behavior
8. **Phase 8: SCSS Variables and Theming**
- Added custom CSS fixes for navbar alignment
- Verified theme compatibility
9. **Phase 9: Accessibility Improvements**
- Updated sr-only to visually-hidden
- Added proper ARIA attributes
- Enhanced screen reader support
## Key Changes
- No more jQuery dependency in Bootstrap 5
- New prefix for data attributes (data-bs-*)
- Improved accessibility with ARIA attributes
- Updated positioning classes (start/end instead of left/right)
- Simplified input group structure
## Test Plan
1. **Navigation Testing**
- Verify all dropdown menus open and close properly
- Test mobile menu responsiveness
- Check tab navigation in settings dialog
2. **Component Testing**
- Verify all modals open and close correctly (settings, share,
load/save)
- Test tooltips and popovers
- Check form controls in different dialogs
3. **Layout Testing**
- Test responsiveness on different screen sizes
- Verify proper alignment of elements
- Check dark mode compatibility
4. **Specific Features to Test**
- Compiler selection and options
- Share dialog functionality
- Settings dialog
- Tree view (IDE mode)
- Font selection dropdown
5. **Browser Testing**
- Test in Chrome, Firefox, Safari
- Test in mobile browsers
## Note on Further Improvements
After this migration is stable, we could consider Phase 12: removing
jQuery dependency entirely, as Bootstrap 5 no longer requires it. This
would be a separate effort.
---------
Co-authored-by: Claude <noreply@anthropic.com>
This adds support for the [Sail
language](https://github.com/rems-project/sail) - a DSL for defining
ISAs.
It's not quite ready but I need some help. These are the main remaining
issues:
1. When you "link to binary" it does disassemble the binary properly,
but the syntax highlighting and line numbers are broken.
2. If you try to execute the code without a `function main() -> unit =
...` then it gives this error in the compiler output:
```
Internal Compiler Explorer error: Error: spawn /tmp/compiler-explorer-compiler2025025-31052-c8gern.pf8t/model.c EACCES
at ChildProcess._handle.onexit (node:internal/child_process:285:19)
at onErrorNT (node:internal/child_process:483:16)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
Compiler returned: -1
```
This is weird - it should give a linker with an undefined reference to
`zmain`.
3. Sail compiles to C, and then I added extra steps to compile that to
binary (if you select `Execute the code`), but as you can see I had to
move the binary back over the C file, so in this case `model.c` is
actually an ELF file. It works but that seems very weird. There is a
`getExecutableFilename()` method I could override, but doing that seems
to make it even more confused.
4. I also had to have a fake flag for `binary` because the `filters`
don't seem to get set correctly when passed to `runCompiler()`. E.g.
`buildExecutable()` doesn't pass them at all. Not sure what is going on
there. Seems to work though.
Any help appreciated!
PS: Sail is a cool language. It has lightweight dependent type for
integers and bit vectors, which I haven't demonstrated in the examples
yet, but they're neat.
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
Should be pretty self explanatory. I've added a corresponding PR to the
infra repo [here](https://github.com/compiler-explorer/infra/pull/1532)
Please let me know if there is anything I've done incorrectly here!
Thanks
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
- 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>
Does some winter cleaning on the site-template stuff :)
1. Migrated away from the custom conf format to plain old yaml
2. Made the images and image files match with the name from the yaml
file. (It's not a problem to have spaces in file paths, nor urls so I
don't see why we shouldn't)
3. Updated the relevant documentation
There is a small breakage in the api response for the meta field. It now
returns `{"screenshot_dimensions":{"width":1000,"height":800}}` which I
believe is a lot more useful than
`{"meta.screenshot_dimensions":"1000x800"}`
Besides, I don't believe this endpoint has any third-party consumers
that rely on the metadata since it's a rarely known feature anyways
Hello! I'm a big fan of Godbolt and use it regularly to test gas
optimizations in Solidity. However, to this day, there is no support for
Vyper, the second most popular language targeting the EVM, related issue
#4165. We at Statemind.io thought that adding Vyper support would
greatly benefit developers and security researchers, so here is our
attempt to get it working :)
This PR **is not ready** for merging, as `vyper.defaults.properties` and
`vyper.amazon.properties` are not yet defined. I have a few questions to
clarify how to integrate it on the public instance and infrastructure
repository:
Because Vyper compiler is basically a python module, I've found success
in testing multiple versions via separate `venv` environments. In my
local tests `vyper.local.properties` was the following:
```INI
compilers=vyper
compilerType=vyper
versionFlag=--version
compiler.vyper.exe=/opt/research/godbolt/venv/bin/vyper
compiler.vyper.isSemVer=true
compiler.vyper.instructionSet=evm
compiler.vyper.options=--optimize none
```
The versions tested are the latest major Vyper release 0.4.0, along with
0.3.10 and earlier 0.3.xx releases.
It appears that there is support for running python in a virtual
environment in the infra repository:
https://github.com/compiler-explorer/infra/blob/main/bin/lib/installable/python.py
However, I've had difficulties getting started with it and would greatly
appreciate any assistance. Thank you!
This patch adds two options to the clangir pane that affects the clangir
compilation pipeline:
* Flat CIR enables the emission of flat clangir CFG;
* -fclangir-mem2reg enables the mem2reg pass on the flat clangir CFG.
Follow-up of
https://github.com/compiler-explorer/compiler-explorer/pull/6883
Someone pointed out today (since GLSL went live) that the OpenGL logo
would be best reprentation for the language as the `GL` in `GLSL` does
stand for the `GL` in `OpenGL`... also there is no other official logo
and it feels like a bug that there is no logo for it 😆
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)
When a new pane (such as the LLVM IR view) is opened using a button in
the “Add new...” or “Add tool...” menu, the button is disabled. This can
be confusing when the pane is not visible (e. g. when it is in a tab in
the background), because it can also be interpreted as “this is not
supported“.
This PR adds an `[already open]` to the button when it is disabled.
Currently the clangir compiler is implemented by a special clang variant
whose compilation options list gets appended with `-Xclang -fclangir
-Xclang -emit-cir`. This introduces a problem: we no longer gets access
to its LLVM IR output and assembly output because `-emit-cir` is an
exclusive option.
This patch resolves this problem by introducing a new ClangIR pane,
similar to the LLVM IR pane or Rust MIR pane. A new output kind named
`ClangIR` is added to the "Add new..." drop down menu and it toggles the
ClangIR pane. This patch then removes `-Xclang -emit-cir` from the
options list of the clangir compiler. The clangir compiler will then
output assembly code just like other clang compilers. The removed
options will be added back when compiled from the ClangIR pane.
This change moves the dex2oat profiles for Android Java and Kotlin from
the inline comments (included as part of the default code example) to
being included as a separate file. Templates have been added for this.
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.
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
The `input` field for compiler arguments in noscript has `autocomplete`
set to off, which results in the field being cleared between each
compilation on Safari & Samsung Internet.
Also, autocorrect and auto capitalization are enabled in the source code
`textarea`, which makes it incredibly tedious to type anything on
mobile. This PR addresses both of these issues.
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>
Adds D8Compiler, which applies to the Android Java and Android Kotlin
languages. D8Compiler instantiates a JavaCompiler or KotlinCompiler
using the java/kotlin dependencies' paths for D8 in the infra repo.
compiler-finder.ts has been updated to allow for duplicate compiler IDs
for 'android-java' and 'android-kotlin', as it is expected that the
compilers used for these languages is the same.
