mirror of
https://github.com/compiler-explorer/compiler-explorer.git
synced 2026-05-16 07:51:41 -04:00
f3e27510f6
## Summary
bronto-refactor emits the refactored source on stdout. The default
`parseOutput` pipeline includes a `FileWithLineMessage` matcher whose
regex (`SOURCE_WITH_FILENAME` in `lib/utils.ts`) is permissive enough to
mistake any C++ member call with a numeric first argument — e.g.
`r.fetch_add(2, std::memory_order_relaxed);` — for a `filename:line:`
reference, treating `r.fetch_add` as a filename and `2` as a line
number. The result was fake red error squigglies in the editor, with the
trailing `, std::memory_order_relaxed);` shown as the diagnostic
message.
`BrontoRefactorTool` now overrides `parseOutput` to drop
`FileWithLineMessage`. `SourceWithLineMessage` is kept so genuine
`<source>:N:M:` diagnostics on stderr still surface.
Reported via the web UI when running bronto-refactor on this:
```cpp
#include <atomic>
void foo(std::atomic<int>& r) {
r.fetch_add(2, std::memory_order_relaxed);
r.fetch_add(4, std::memory_order_relaxed);
}
```
## Out of scope
The `SOURCE_WITH_FILENAME` regex in `lib/utils.ts:154` is genuinely too
loose — any tool whose stdout is source-like (formatters, refactorers)
can hit this. Tightening it (require an extension, or `:`-only
separator) is a separate change since it touches every compiler/tool
that relies on `parseOutput`.
## Test plan
- [x] Added `test/tool-tests.ts` case asserting refactored source
produces no tags.
- [x] Added a second case asserting a real `<source>:N:M:` diagnostic on
stderr is still tagged (so we didn't over-blunt the parser).
- [x] Verified the first test fails on `main` and passes with the fix.
- [x] `npm run ts-check`, `npm run lint`, `npm run test -- --run
tool-tests` all pass.
- [ ] Confirm in the web UI that the original repro no longer shows
squigglies.
cc @fowles
Co-authored-by: mattgodbolt-molty <mattgodbolt-molty@users.noreply.github.com>