This PR includes various documentation improvements:
- Fix grammar in README.md introduction
- Update Node.js version references to consistently indicate 'Node.js 20
or higher'
- Enhance macOS installation and setup guide with detailed instructions
- Fix broken link in API.md
- Fix formatting inconsistencies in WhatIsCompilerExplorer.md
🤖 Generated with [Claude Code](https://claude.ai/code)
---------
Co-authored-by: Claude <noreply@anthropic.com>
This PR adds a detailed Configuration.md document that comprehensively
explains the Compiler Explorer configuration system. It covers:
- Configuration file structure and hierarchical loading
- Property types and automatic conversions
- List separators and specialized formats
- Group inheritance and compiler configuration
- Variable substitution mechanisms
- Advanced features like remote compilers and property debugging
Additionally, it updates all related documentation to reference this
central document for configuration details, reducing duplication and
ensuring consistency.
This document will serve as the foundation for future configuration
system improvements by providing clear documentation of the current
implementation.
- Mark documentation update tasks as complete
- Add a comprehensive documentation section for custom component implementations
- Document key changes between Bootstrap 4 and 5 for each component type
- Add sections on event handling, CSS class changes, and special integration notes
- Track remaining tasks with GitHub issues (#7602, #7603, #7604)
- Update references from "beta site" to "live site"
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
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>
[ORCA/C](https://github.com/byteworksinc/ORCA-C) is a C compiler that
natively runs on and targets the Apple IIGS. ORCA/C and the programs it
generates can be run on modern Linux systems by using an emulation tool
called [Golden Gate](https://goldengate.gitlab.io).
This adds support for ORCA/C (run via Golden Gate) in Compiler Explorer.
It uses its own assembly format and objdumper (provided by Golden Gate),
so support for those is added. An extra configuration option was also
added to support execution via an emulator, bypassing the usual check
that executables can run natively. Asm docs for the WDC 65C816 processor
were also added.
ORCA/C and Golden Gate are not Free Software, but their rights holders
have given permission for them to be used on Compiler Explorer. Tarballs
for them can be supplied privately. See infra PR:
compiler-explorer/infra#1521
---------
Co-authored-by: Matt Godbolt <matt@godbolt.org>
<!-- 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!
-->
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
- Ensure MSVC license terms are clearly shown to the user.
- Simplify config of vc and vcpp slightly by extracting common stuff
into a group.
- Remove reference to MS privacy policy
Instead of having several globals, set via environment variables,
explicitly set the "correct" env var if passed `--tmpDir` and then
consistently use it in the rest of the program.
See @apmorton's comments in #1707
# Cerberus
[Cerberus](https://www.cl.cam.ac.uk/~pes20/cerberus/) offers executable
semantics for a substantial fragment of C and
CHERI-C languages. It is implemented via an elaboration into a simpler
Core language, which is displayed as the compiler
output in the Compiler Explorer. Evaluation of C programs (execution) is
also supported.
## Prerequisites
The easiest way to install both the Cerberus and Cerberus-CHERI
compilers is by using Docker:
`docker pull vzaliva/cerberus-cheri`
Then, for example, you can print the _Core_ elaboration for `test.c`
using ISO C semantics:
`docker run -v $HOME/tmp:/mnt -it vzaliva/cerberus-cheri cerberus
--pp=core --exec /mnt/test.c`
## Configuration
The file `etc/config/c.defaults.properties` defines a group of two
compilers: 'cerberus' for ISO C and 'cerberus-cheri'
for CHERI-C. It assumes that the corresponding executables are in the
path.
## Limitations and Future Improvement
Presently, only simple Core output is shown. It is not syntactically
highlighted nor linked to C source code locations.
Some potential future improvements include:
1. Error location handling in warning and error messages
2. Specifying execution flags
3. Core syntax highlighting
4. Display of AST
5. Display of other intermediate languages (Cabs, Ail)
6. Tooltips/links to the ISO C document from Core annotations
## See also:
- [Cerberus (project page)](https://www.cl.cam.ac.uk/~pes20/cerberus/)
- [Cerberus (GitHub
repository)](https://github.com/rems-project/cerberus)
- ["Formal Mechanised Semantics of CHERI C: Capabilities, Undefined
Behaviour, and Provenance" (paper,
preprint)](https://zaliva.org/cheric-asplos24.pdf)
- ["CHERI C semantics as an extension of the ISO C17 standard" (tech
report)](https://www.cl.cam.ac.uk/techreports/UCAM-CL-TR-988.html)
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.
While reading the (excellent) documentation here, I noticed a few stale
references to `.js` files that are now implemented in TypeScript.
* Update `*.js` to `*.ts` in Markdown documentation.
* Update `app.js` to `out/dist/app.js` in
`docs/SystemdSocketActivation.md`.
_I managed to follow these instructions and locally run Compiler
Explorer through socket activation after that change._
* Update `*.js` to `*.ts` in the GitHub labeller config
`.github/labeler.yml`.
_Also correct some misnamed files here. I have checked the new version
with `ls $(grep -E "^ - " .github/labeler.yml | sed "s/ - //g")`. If I
were more familiar here, I would have liked to add a similar check to
the automated tests._
- Sheepishly add myself to the contributors list, despite this being a
tiny find-and-replace change.
---------
Co-authored-by: Jeremy Rifkin <51220084+jeremy-rifkin@users.noreply.github.com>
Attempt to fix#5476. As far as I can tell `process.env.winTmp` is
needed just for windows executables and WslVcCompiler. It should be
possible to just ignore the exec error and continue. If for some reason
the user doesn't have windows paths in their WSL but does want to run
windows executables they can pass `-tmpDir`.
I like the new "what is compiler explorer" very much. Thank you for
doing it. I did a little bit of wordsmithing as I thought the intro
needed some ironing out.
