- 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>
- Converts all "wine" compilers to be "ex wine" in Windows. uses
different IDs to avoid clashes BUT aliases in the old IDs.
- removes wine and firejail config
Bumps [tmp](https://github.com/raszi/node-tmp) from 0.2.3 to 0.2.4.
<details>
<summary>Commits</summary>
<ul>
<li><a
href="08fa3abac3"><code>08fa3ab</code></a>
Update version</li>
<li><a
href="1cf4ec5418"><code>1cf4ec5</code></a>
Merge commit from fork</li>
<li><a
href="188b25e529"><code>188b25e</code></a>
Fix GHSA-52f5-9888-hmc6</li>
<li><a
href="73b9fe45bb"><code>73b9fe4</code></a>
Add test case for GHSA-52f5-9888-hmc6</li>
<li><a
href="b8e2f29a75"><code>b8e2f29</code></a>
Remove broken tests</li>
<li><a
href="2892a027b4"><code>2892a02</code></a>
Remove outdated URL</li>
<li><a
href="f592318246"><code>f592318</code></a>
Reformat package.json</li>
<li><a
href="995ac8cc45"><code>995ac8c</code></a>
Merge pull request <a
href="https://redirect.github.com/raszi/node-tmp/issues/301">#301</a>
from raszi/dependabot/npm_and_yarn/braces-3.0.3</li>
<li><a
href="caa758d7b5"><code>caa758d</code></a>
Bump braces from 3.0.2 to 3.0.3</li>
<li>See full diff in <a
href="https://github.com/raszi/node-tmp/compare/v0.2.3...v0.2.4">compare
view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't
alter it yourself. You can also trigger a rebase manually by commenting
`@dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits
that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot squash and merge` will squash and merge this PR after
your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
and block automerging
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot close` will close this PR and stop Dependabot recreating
it. You can achieve the same result by closing it manually
- `@dependabot show <dependency name> ignore conditions` will show all
of the ignore conditions of the specified dependency
- `@dependabot ignore this major version` will close this PR and stop
Dependabot creating any more for this major version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this minor version` will close this PR and stop
Dependabot creating any more for this minor version (unless you reopen
the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop
Dependabot creating any more for this dependency (unless you reopen the
PR or upgrade to it yourself)
You can disable automated security fix PRs for this repo from the
[Security Alerts
page](https://github.com/compiler-explorer/compiler-explorer/network/alerts).
</details>
Signed-off-by: dependabot[bot] <support@github.com>
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
- Add comprehensive test suite covering all Claude Explain functionality:
- Basic pane opening and consent flow
- no-ai directive detection
- API interactions and error handling
- Options/customization features
- Caching behavior and persistence
- Compilation state handling
- State persistence across page loads
- Fix caching bug in explain-view.ts:
- Cache was incorrectly implemented as instance variable, losing cached explanations when panes were closed/reopened
- Made cache static to persist across all pane instances (matches consent persistence pattern)
- Fixes failing "Caching and reload" Cypress test
- Aligns implementation with documented behavior: "shared across all explain views in the session"
- Add test utilities and helpers:
- Monaco editor content manipulation using clipboard events
- Claude Explain specific helpers moved to test file
- General utilities remain in utils.ts
- Performance optimizations:
- Clear Cypress intercepts in afterEach to prevent O(n²) degradation
- Use :visible selectors to avoid GoldenLayout template elements
- Proper mock setup timing to prevent race conditions
- Add comprehensive README with lessons learned and best practices
All tests use fake test data (test_first, focus_a, etc.) to clearly distinguish from production values and prevent accidental API calls.
## Problem
The SCSS migration encountered issues with Golden Layout CSS imports:
1. Sass `@import` statements are deprecated and will be removed in Dart
Sass 3.0.0
2. `@use` cannot be used inside conditional blocks like
`html[data-theme='default']`
3. The `~` webpack resolver doesn't work with `@use`, only `@import`
Current problematic code:
```scss
html[data-theme='default'] {
@import '~golden-layout/src/css/goldenlayout-light-theme';
}
```
## Solution
Added a custom webpack loader that automatically inlines Golden Layout
CSS content at build time.
**Custom Loader** (`etc/webpack/replace-golden-layout-imports.js`):
- Detects `@import` statements for `~golden-layout/src/css/*` files
- Reads CSS content from `node_modules/golden-layout/src/css/`
- Replaces import statements with actual CSS content
- Uses generalized regex to handle any golden-layout CSS file
**Integration & Cleanup**:
- Positioned before sass-loader in webpack processing chain
- Automatically syncs with Golden Layout package updates
- Consolidated all webpack loaders in `etc/webpack/` directory
- Moved pug loader from `etc/scripts/parsed-pug/` to `etc/webpack/`
- Converted both loaders to ES modules for consistency
- Removed unnecessary `package.json` override
## Result
Eliminates Sass deprecation warnings while preserving existing theme
architecture. Build-time processing with no runtime overhead. Cleaner
webpack loader organization.
## Files Changed
- `webpack.config.esm.ts` - Updated loader paths and added Golden Layout
processor
- `etc/webpack/replace-golden-layout-imports.js` - Custom loader
implementation
- `etc/webpack/parsed-pug-loader.js` - Moved from
`etc/scripts/parsed-pug/` and converted to ES modules
- Removed `etc/webpack/package.json` - No longer needed with ES modules
- Removed `etc/scripts/parsed-pug/` directory - Consolidated into
webpack directory
---------
Co-authored-by: Claude <noreply@anthropic.com>
Add Claude Explain feature for AI-powered code explanations
This PR introduces Claude Explain, a new feature that provides AI-powered explanations of compiler output directly within Compiler Explorer.
Key features:
Claude Explain functionality:
- New explain view pane
- Explains compiler output with full context of source code and compilation output
- Configurable audience level and explanation type
- Response caching to improve performance and reduce API calls
- Usage statistics display showing requests used and token counts
User experience:
- Consent flow on first use explaining data handling and privacy
- AI disclaimer banner warning about potential LLM inaccuracies
- Respects "no-ai" directive in source code for users who don't want AI processing
Privacy and security:
- Data sent to Anthropic's Claude API as documented in privacy policy
- No data used for model training
- Clear consent required before first use
- Support for opting out via "no-ai" directive
The feature is marked as beta and can be enabled via configuration.
Co-authored-by: Claude <noreply@anthropic.com>
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.
