fix: instrument-hooks build failure on preview runner

[not-matthias]

No description provided.

[codspeed-hq]

Merging this PR will not alter performance

⚠️ Unknown Walltime execution environment detected

Using the Walltime instrument on standard Hosted Runners will lead to inconsistent data.

For the most accurate results, we recommend using CodSpeed Macro Runners: bare-metal machines fine-tuned for performance measurement consistency.

✅ 48 untouched benchmarks
🆕 1 new benchmark
⏩ 1 skipped benchmark¹

Performance Changes

	Benchmark	BASE	HEAD	Efficiency
🆕	BenchmarkFibonacciDarwin	N/A	250.8 µs	N/A

---

_{Comparing cod-2942-go-runner-fails-to-compile-instrument-hooks-generated-c-on (c102c1a) with main (f6291c8)}

Footnotes

1. 1 benchmark was skipped, so the baseline result was used instead. If it was deleted from the codebase, click here and archive it to remove it from the performance reports. ↩

[greptile-apps]

Greptile Summary

This PR fixes a build failure for instrument-hooks on the preview runner by adding -std=c11 to the #cgo CFLAGS in instrument-hooks.go, and cleans up a temporary CI workaround that had pinned the macOS benchmark job to a specific runner branch.

• instrument-hooks.go: Adds -std=c11 to #cgo CFLAGS so that core.c is compiled with an explicit C11 standard, resolving the preview-runner build failure.
• ci.yml: Removes the branch-pinned runner-version: branch:cod-2762-samply-sigkills-dsymutil workaround (and its accompanying TODO) and restores runner-version: latest now that the upstream runner fix has shipped.

Confidence Score: 4/5

Safe to merge — the CFLAGS change fixes a real build failure and the CI cleanup is straightforward.

The core change is small and targeted: adding -std=c11 to the cgo CFLAGS so the embedded core.c is compiled with an explicit C standard. The only open question is whether strict c11 (no GNU extensions) vs gnu11 (C11 + GNU extensions) is the right dialect, given that -Wno-incompatible-pointer-types hints at non-standard pointer usage in core.c. If core.c relies on any GNU-only constructs, a future compiler or platform change could surface a failure that gnu11 would have avoided. The CI change — dropping the branch-pinned runner workaround — is unambiguously correct.

go-runner/overlay/instrument-hooks.go warrants a second look on the choice of -std=c11 vs -std=gnu11.

Important Files Changed

Filename	Overview
go-runner/overlay/instrument-hooks.go	Adds -std=c11 to cgo CFLAGS to fix build failure on preview runner; minor concern around using strict c11 vs gnu11 dialect given the pre-existing -Wno-incompatible-pointer-types flag
.github/workflows/ci.yml	Removes temporary branch-pinned runner workaround and restores runner-version to latest, cleaning up the now-resolved TODO

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[cgo build of instrument-hooks.go] --> B["CFLAGS: -std=c11 (NEW) + -Wno-* flags"]
    B --> C["C compiler compiles core.c"]
    C -->|"Before fix: preview runner failed"| D["Build failure on preview runner"]
    C -->|"After fix: explicit C11 dialect"| E["Successful compilation"]
    E --> F[Go binary with CGO InstrumentHooks]
    G[CI: walltime-macos-test] -->|"Was pinned to branch runner"| H["runner-version: branch:cod-2762-..."]
    G -->|"Now restored"| I["runner-version: latest"]

Loading

%%{init: {'theme': 'base', 'themeVariables': {"darkMode": true, "background": "#0d1117", "primaryColor": "#21262d", "primaryTextColor": "#e6edf3", "primaryBorderColor": "#8b949e", "lineColor": "#8b949e", "textColor": "#e6edf3", "edgeLabelBackground": "#161b22", "actorBkg": "#21262d", "actorBorder": "#8b949e", "actorTextColor": "#e6edf3", "actorLineColor": "#8b949e", "signalColor": "#8b949e", "signalTextColor": "#e6edf3", "noteBkgColor": "#373320", "noteBorderColor": "#d4a72c", "noteTextColor": "#f0e6c0", "labelBoxBkgColor": "#21262d", "labelBoxBorderColor": "#8b949e", "labelTextColor": "#e6edf3", "loopTextColor": "#e6edf3", "activationBkgColor": "#30363d", "activationBorderColor": "#8b949e"}}}%%
flowchart TD
    A[cgo build of instrument-hooks.go] --> B["CFLAGS: -std=c11 (NEW) + -Wno-* flags"]
    B --> C["C compiler compiles core.c"]
    C -->|"Before fix: preview runner failed"| D["Build failure on preview runner"]
    C -->|"After fix: explicit C11 dialect"| E["Successful compilation"]
    E --> F[Go binary with CGO InstrumentHooks]
    G[CI: walltime-macos-test] -->|"Was pinned to branch runner"| H["runner-version: branch:cod-2762-..."]
    G -->|"Now restored"| I["runner-version: latest"]

Loading

_{Reviews (1): Last reviewed commit: "ci: use latest runner-version for benchm..." | Re-trigger Greptile}

[greptile-apps]

Strict C11 vs GNU11 dialect

-std=c11 enables C11 but disables GNU language extensions (e.g. __attribute__ extensions, statement expressions, nested functions). The already-present -Wno-incompatible-pointer-types suggests core.c is not fully standards-clean, so there is a latent risk that code which compiles now under the platform's default dialect (gnu17 on recent GCC, gnu17 on Apple Clang) would fail if any GNU-only construct is reached. -std=gnu11 gives you all of C11 while keeping GNU extensions available — if the root cause of the preview-runner failure was the compiler defaulting below C11, gnu11 would fix it equally and leave less room for future breakage.

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!