In PR https://github.com/compiler-explorer/compiler-explorer/pull/7976,
I forgot to handle the case where same instructions have different
descriptions. This PR fixes the script and removes the duplicates from
the generated file.
The SASS docs are extracted from multiple tables from
https://docs.nvidia.com/cuda/cuda-binary-utilities/index.html#instruction-set-reference.
For example,
- Table 4. Maxwell and Pascal Instruction Set
- ...
- Table 8. Hopper Instruction Set
- Table 8. Blackwell Instruction Set (wait...what? both tables are table
8? whatever...)
Previously, only the duplications for the (opcode, descriptions) pair
were removed. In this PR, we only check the duplications based on the
opcode and only keep the last one (based on the assumption that the
newer ones are better).
I manually went through the removed duplicates, and found that
- No instruction actually changed the meaning across generations (I
would be very surprised if they did so).
- Most of the changes are minor fixes like changing capitalization
(e.g., `generic Memory` -> `Generic Memory`) or fixing typo (e.g.,
`Local within Shared Memory Window` -> `Load within Shared Memory
Window`)
- A couple of the descriptions are for whatever reason simplified (e.g.,
`LOP3`: `3-input Logic Operation` -> `Logic Operation`), which is a bit
unfortunate.
A whole bunch of changes I've been meaning to make:
- Clarify things and put the TLDR at the top
- Remove my own darn address etc (after checking this is OK)
- Clarifying the goo.gl situation
- Paving the way for the explain feature
## Summary
This PR completes Phase 2 of the SCSS migration to prepare for Dart Sass
3.0.0 compatibility. This phase focused on converting the complex
conditional theme system from deprecated `@import` statements to modern
`@use` statements.
## What Changed
### 🎯 Major Achievements
- **Eliminated 43+ SCSS deprecation warnings** (down from 45+ to only 2
remaining)
- **96% reduction** in deprecation warnings
- **Converted all SCSS-to-SCSS imports** from `@import` to `@use`
- **Modernized all color functions**: `lighten()`, `darken()`,
`adjust-color()`, `transparentize()`, `opacify()` → `color.scale()` and
`color.adjust()`
- **Implemented CSS custom properties** for theme variable sharing
- **Fixed theme isolation** - themes now properly scope their styles
### 🔧 Technical Changes
- Added `@use` statements for all theme files at top of `explorer.scss`
- Wrapped all theme file contents in `html[data-theme='...']` selectors
- Added CSS custom properties (`:root { --lighter: #{$lighter}; }`) for
theme variables
- Scoped custom golden-layout themes within their respective theme
selectors
- Removed all conditional `@import` statements for SCSS files
### 📁 Files Modified
- `static/styles/explorer.scss` - Added theme `@use` statements, removed
conditional imports
- `static/styles/themes/pink-theme.scss` - Scoped all styles, added CSS
custom properties
- `static/styles/themes/one-dark-theme.scss` - Scoped all styles, added
CSS custom properties
- `static/styles/themes/dark-theme.scss` - Scoped all styles
- `static/styles/themes/default-theme.scss` - Scoped all styles
- `static/styles/themes/custom-golden-layout-themes/pink.scss` - Scoped
to pink theme
- `static/styles/themes/custom-golden-layout-themes/one-dark.scss` -
Scoped to one-dark theme
## Remaining Issues (Phase 3)
⚠️ **2 deprecation warnings remain** - these will eventually break in
Dart Sass 3.0.0:
```
Line 1161: @import '~golden-layout/src/css/goldenlayout-light-theme';
Line 1168: @import '~golden-layout/src/css/goldenlayout-dark-theme';
```
These are external CSS imports from the golden-layout library that
cannot be converted to `@use` because:
1. They're CSS files, not SCSS files
2. They use webpack's `~` syntax for node_modules resolution
3. They're conditionally imported based on theme
**Phase 3 will need to address these** by either:
- Converting to regular CSS `@import` at top level
- Using webpack's CSS importing mechanism
- Including CSS files directly in HTML
- Finding alternative golden-layout integration approach
## Testing
- ✅ Webpack build succeeds with only 2 expected warnings
- ✅ Visual testing confirms themes work correctly
- ✅ Pink theme now shows proper light golden-layout theme (was showing
dark before)
- ✅ All theme styles properly isolated - no global style conflicts
- ✅ CSS custom properties working for theme variables
## Build Output
Current warnings (only external CSS imports remain):
```
WARNING: Sass @import rules are deprecated and will be removed in Dart Sass 3.0.0
Line 1161: @import '~golden-layout/src/css/goldenlayout-light-theme';
Line 1168: @import '~golden-layout/src/css/goldenlayout-dark-theme';
```
All other webpack warnings are performance-related (bundle sizes), not
SCSS deprecations.
## Migration Progress
- ✅ **Phase 1**: Basic color function and simple import conversions
(merged)
- ✅ **Phase 2**: Complex conditional theme system conversion (this PR)
- 🔄 **Phase 3**: External CSS import resolution (future work)
This PR makes Compiler Explorer's SCSS mostly compatible with Dart Sass
3.0.0, with only 2 external library imports remaining to be addressed.
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
Fix issue with AMD by removing the dependency on lld (tested locally by
moving `/usr/bin/ld.lld` and `/opt/rocm/llvm/bin/ld.lld`)
```
File "/opt/compiler-explorer/triton/v3.3.1/lib/python3.12/site-packages/triton/runtime/jit.py", line 347, in <lambda>
return lambda *args, **kwargs: self.run(grid=grid, warmup=False, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/compiler-explorer/triton/v3.3.1/lib/python3.12/site-packages/triton/runtime/jit.py", line 569, in run
kernel = self.compile(src, target=target, options=options.__dict__)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/compiler-explorer/triton/v3.3.1/lib/python3.12/site-packages/triton/compiler/compiler.py", line 230, in compile
key = f"{triton_key()}-{src.hash()}-{backend.hash()}-{options.hash()}-{str(sorted(env_vars.items()))}"
^^^^^^^^^^^^^^
File "/opt/compiler-explorer/triton/v3.3.1/lib/python3.12/site-packages/triton/backends/amd/compiler.py", line 418, in hash
version = subprocess.check_output([HIPBackend.path_to_rocm_lld(), "--version"], encoding='utf-8')
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/compiler-explorer/triton/v3.3.1/lib/python3.12/site-packages/triton/backends/amd/compiler.py", line 197, in path_to_rocm_lld
raise Exception("ROCm linker /opt/rocm/llvm/bin/ld.lld not found. Set 'TRITON_HIP_LLD_PATH' to its path.")
Exception: ROCm linker /opt/rocm/llvm/bin/ld.lld not found. Set 'TRITON_HIP_LLD_PATH' to its path.
```
## Summary
This PR fixes Sentry issue COMPILER-EXPLORER-BFA which has generated
over 33,000 occurrences of non-actionable error reports.
## Problem
The issue occurs when jQuery `.get()` requests fail with `readyState: 0`
and `status: 0`, which typically indicates:
- Ad blockers blocking requests to static assets (icons.html,
sponsors.html)
- Network connectivity issues
- Browser security policies
- User navigating away during request
These network-level failures are not application bugs and create noise
in Sentry monitoring.
## Solution
- Filter out network failures (`readyState === 0 && status === 0`)
before sending to Sentry
- Only capture actual server errors (`status >= 400`) for debugging
- Log network failures to console for debugging instead
- For sponsors.html specifically, silently fail on network issues per
request
## Test Plan
- [x] TypeScript compilation passes
- [x] All tests pass
- [x] Pre-commit hooks complete successfully
- Verified logic handles both network failures and real server errors
appropriately
🤖 Generated with [Claude Code](https://claude.ai/code)
## Summary
**Phase 1 of systematic SCSS modernization** to prepare for Dart Sass
3.0.0 compatibility. This PR eliminates **all deprecated color function
warnings** and converts straightforward `@import` statements to modern
`@use` syntax.
## What This PR Accomplishes
### ✅ **All Color Function Deprecations Eliminated** (11 instances)
- `adjust-color()` → `color.adjust()` (5 instances in `colours.scss`)
- `lighten()` → `color.scale($lightness: +%)` (2 instances in
`dark-theme.scss`)
- `darken()` → `color.scale($lightness: -%)` (4 instances across themes)
- Added `@use 'sass:color'` imports to all theme files
### ✅ **@import to @use Conversion** (4 instances)
- Internal SCSS-to-SCSS imports converted to modern `@use` syntax
- `ansi-dark.scss` imports in theme files
- Custom golden layout theme imports
- All `@use` statements properly moved to top of files per SCSS
requirements
### ✅ **Zero Visual Changes**
- All themes render identically to before
- Extensive testing across all 4 themes (default, dark, pink, one-dark)
- Build process unchanged, functionality preserved
## Technical Approach
**5 incremental commits** with systematic validation at each step:
1. Add `@use 'sass:color'` imports (preparation)
2. Convert `colours.scss` color functions
3. Convert `dark-theme.scss` color functions
4. Convert remaining theme color functions
5. Convert internal SCSS `@import` to `@use`
Each commit was individually tested for build success and visual
consistency.
## What This PR Does NOT Include
This is **Phase 1 only** - the following complex migrations are
intentionally deferred to **Phase 2**:
### 🔄 **Remaining for Phase 2: Architectural Changes**
- **Complex conditional theme system** in `explorer.scss` (lines
1157-1180)
- Currently uses HTML attribute-based conditional `@import` statements
- Requires architectural redesign (CSS variables or separate entry
points)
- **CSS imports from node_modules** (FontAwesome, Golden Layout)
- Kept as `@import` due to webpack compatibility requirements
- **Theme switching mechanism** updates if needed
### 📊 **Migration Progress**
- ✅ **Phase 1**: Color functions + simple imports (this PR)
- 🔄 **Phase 2**: Conditional theme system redesign
- 🔄 **Phase 3**: Final cleanup and optimization
## Deprecation Warning Reduction
**Before this PR**: 45+ deprecation warnings
**After this PR**: ~15 deprecation warnings (only complex `@import`
statements remain)
All remaining warnings are the challenging conditional imports that
require Phase 2 architectural work.
## Testing
- ✅ Build succeeds: `npm run webpack`, `npm run ts-check`, `npm run
lint`
- ✅ All themes render correctly: default, dark, pink, one-dark
- ✅ No visual regressions or functional changes
- ✅ Theme switching works identically
- ✅ Form controls, scrollbars, and all UI elements maintain proper
styling
## Benefits
1. **Future-proofing**: Ready for Dart Sass 3.0.0 color function changes
2. **Maintainability**: Modern, namespaced color functions are clearer
3. **Performance**: Modern `@use` system loads modules once vs `@import`
duplication
4. **Incremental approach**: Safe, testable changes with easy rollback
if needed
## Follow-up Work
This establishes the foundation for **Phase 2**, which will tackle the
complex conditional theme system. The architectural decisions for Phase
2 can now be made independently without blocking this foundational
modernization.
Closes part of #7112🤖 Generated with [Claude Code](https://claude.ai/code)
Co-Authored-By: Claude <noreply@anthropic.com>
---------
Co-authored-by: Claude <noreply@anthropic.com>
After directive filtering, there will be dangling `{}` spanning two
lines. This PR attempts to remove them.
For example,
```
.section .debug_abbrev
{
.b8 1
}
.section .debug_info
{
.b32 70
.b32 .debug_abbrev
}
```
The above assembly used to become the following text after filtering
directive
```
{
}
{
}
```
Recogonize lines with predicate (e.g., `@%p1`, `@!%p1`) as instructions:
- `@%p1 ld.global.v4.b32 { %r9, %r10, %r11, %r12 }, [ %rd3 + 0 ];`
- `@%p2 bra $L__BB0_28;`
- `@!%p2 bra $L__BB0_28;`
| Before | After |
| --- | --- |
| <img width="580" height="320" alt="image"
src="https://github.com/user-attachments/assets/c3913b09-ce04-44c5-a4c0-fa69805cf1d7"
/> | <img width="566" height="323" alt="image"
src="https://github.com/user-attachments/assets/08308b3d-df00-4cf1-8321-203c374c27c3"
/> |
From
https://docs.nvidia.com/cuda/parallel-thread-execution/#instruction-statements:
> Instructions have an optional guard predicate which controls
conditional execution. The guard predicate follows the optional label
and precedes the opcode, and is written as @p, where p is a predicate
register. The guard predicate may be optionally negated, written as @!p.
Implementation-wise, added `(@!?%\w+\s+)?` to existing default
`hasOpcodeRe` (`/^\s*(%[$.A-Z_a-z][\w$.]*\s*=\s*)?[A-Za-z]/`)
Fixed the SCSS deprecation warnings in three themes - default, one-dark,
and pink.
- Replaced deprecated lighten() and darken() functions with
color.adjust()
- Add @use 'sass:color' imports to all theme files
- Add standard background-clip property alongside
-webkit-background-clip for CSS compatibility
- Fixes the warnings for the files mentioned in #7112: 45 SCSS
deprecation warnings
I tried the automatic migrator mentioned in #7112 and here's how it
went:
What worked perfectly:
Color function migration: npx sass-migrator color successfully converted
all deprecated color functions:
lighten($color, 10%) → color.adjust($color, $lightness: 10%)
darken($color, 15%) → color.adjust($color, $lightness: -15%)
Individual theme file migration: npx sass-migrator module worked well
for standalone theme files like:
static/styles/themes/default-theme.scss
static/styles/themes/pink-theme.scss
static/styles/themes/one-dark-theme.scss
Automatic @use imports: The migrator correctly added @use 'sass:color';
imports at the top of files
However, the migrator couldn't handle:
Complex nested import structures: The conditional theme loading system
in static/styles/explorer.scss was too complex for automatic migration.
and Conditional @import statements in explorer.scss: The migrator failed
on lines like: &[data-theme='pink'] {
@import 'themes/pink-theme';
}
Therefore the migrator can be used in conjunction with manual editing of
files.
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>
This PR fixes the "unassigned file number" error in llvm-mca when
processing GCC-generated assembly with debug information #6795 .
**Problem**: GCC with `-g` flag generates `.loc` and `.file` debug
directives that cause llvm-mca to fail with "unassigned file number"
errors.
**Solution**: Filter out `.loc` and `.file` directives during assembly
preprocessing, similar to how other problematic directives are already
handled.
**Changes**:
- Add regex filtering for `.loc` and `.file` directives in
`rewriteAsm()`
- Make `rewriteAsm()` method public for testability
- Add comprehensive test coverage for debug directive removal
The fix is minimal, targeted, and follows the existing pattern of
directive filtering.
A while ago compiler explorer would only see exported functions of the
main package (and the main function).
I don't know when but at someone improved the flags passed to the go
compiler and it now sees all functions, even if you use the oldest go
compiler still supported.
Remove noise from the example and make it more like the C one.
## Summary
- Suppress "Object Not Found Matching Id" errors from CEFSharp bots
- Generalizes existing suppression for Id:2 to catch all Id values
- Analysis shows 100% of these 76,000+ errors come from Windows + Chrome
(CEFSharp signature)
## Background
We're seeing thousands of `Object Not Found Matching Id:1,
MethodName:update, ParamCount:4` errors in Sentry. Investigation
reveals:
1. **These are bot errors, not user errors** - The error format is
specific to CEFSharp (.NET Chromium wrapper) used by automated scanners
2. **100% come from Windows + Chrome** - Analysis of all events shows
this consistent pattern, confirming they're from CEFSharp bots
3. **Likely Microsoft Outlook SafeLink** - Based on similar reports from
other projects, these are URL security scanners
4. **We already suppress Id:2** - PR #7103 added suppression for the
same error with Id:2
## Changes
Updated the Sentry ignore pattern from `/Object Not Found Matching
Id:2/` to `/Object Not Found Matching Id:\d+/` to catch all variants.
## References
- Similar issue reported:
https://github.com/DataDog/browser-sdk/issues/2715
- TrackJS documentation:
https://trackjs.com/javascript-errors/object-not-found-matching-id-methodname-paramcount/
- Previous PR that added Id:2 suppression: #7103
## Test plan
- [x] TypeScript checks pass
- [x] Tests pass
- [x] Pre-commit hooks pass
cc @OfekShilon - could you review this since you added the original
suppression?
🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
- Add nix.amazon.properties with proper executable paths
- Define 4 Nix versions: 2.26.3, 2.27.1, 2.28.3, 2.29.0
- Set 2.29.0 as default version
Fixes#7811🤖 Generated with [Claude Code](https://claude.ai/code)
Co-authored-by: Claude <noreply@anthropic.com>
Carefully read the upgrade guide and nothing affects us. Also ran and
looked at all the icons I could thing of, in panes and dropdowns. All
looks good.
- latest biome, and fix its configuration
- fixes "static" content to be globally configured too (instead of
per-line)
- fixes issues:
- imports fixed up
- `Date.now()` vs `+new Date()`
- some unused things `_` prefixed
After discussion with the team, turned off the unused parameter warning.
