Keep frame pointers in Windows release builds with clang-cl

[Jarred-Sumner]

OptionsMSVC.cmake adds /Oy- for Release builds to keep frame pointers. clang-cl drops that flag on x64 (-mframe-pointer=none) and on arm64 it only keeps non-leaf frames.

With clang-cl this now passes /clang:-fno-omit-frame-pointer /clang:-mno-omit-leaf-frame-pointer instead (-mframe-pointer=all on both arches). Real MSVC keeps /Oy-.

Checked with clang-cl -### on LLVM 19, 21 and 22:

flags	x64	arm64
/O2 /Oy-	none	non-leaf
/O2 /clang:-fno-omit-frame-pointer /clang:-mno-omit-leaf-frame-pointer	all	all

The Linux, macOS, FreeBSD and Android Dockerfiles already pass -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer. Windows was the only lane without frame pointers.

Bun side: oven-sh/bun#39865.

[coderabbitai]

Warning

Review limit reached

You’ve reached a temporary PR review limit under our Fair Usage Limits Policy.

Your current included review allowance is based on your included PR review attempts over the past 7 days.

Next review available in: 2 minutes

Limit details: You’ve used all 2 included reviews currently available. Your 56 included PR review attempts over the past 7 days set your current allowance at 2 reviews per hour.

You’re in a promotional period — use the checkbox below to run this review for free:

• Run review for free

_{On-demand reviews are free for the next 31 days. After that, they cost $0.25 per reviewed file.}

How can I continue?

Run this review now using the option above, or comment @coderabbitai review --use-credits.

You can also wait for the limit to reset, then comment @coderabbitai review or push new commits to the PR.

An organization admin can change what happens after included review limits in Billing.

How do review limits work?

CodeRabbit enforces per-developer PR review limits within each organization.

For paid Pro and Pro+ reviews, CodeRabbit uses a developer's included PR review attempts over the past 7 days to set the current hourly allowance. At typical activity levels, the full plan allowance applies. Higher sustained activity can lower the allowance until earlier attempts leave the 7-day window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: ASSERTIVE

Plan: Pro

Run ID: dc4484d1-c7f9-4f73-af13-d457f45f1b52

📥 Commits

Reviewing files that changed from the base of the PR and between b785bfc and f6436a6.

📒 Files selected for processing (1)

• Source/cmake/OptionsMSVC.cmake

---

_{Comment @coderabbitai help to get the list of available commands.}

[claude]

LGTM — straightforward build-flag tweak.

What was reviewed:

• Confirmed COMPILER_IS_CLANG_CL is set in WebKitCommon.cmake:150 before Options${PORT} is included (line 341), so the branch is reachable.
• /Gw /Gy /GF are preserved in both branches; only /Oy- is swapped for the /clang: frame-pointer flags.
• Matches the -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer already used on Linux/macOS lanes.

Extended reasoning...

Overview

Single-file change to Source/cmake/OptionsMSVC.cmake. Inside the existing Release build-type block, it splits the add_compile_options(/Oy- /Gw /Gy /GF) line into a clang-cl branch (using /clang:-fno-omit-frame-pointer /clang:-mno-omit-leaf-frame-pointer) and a fallback branch that keeps /Oy-. The other three flags (/Gw /Gy /GF) are unchanged in both paths.

Security risks

None. This is a compiler-flag adjustment that keeps frame pointers in release binaries. No auth, crypto, permissions, or runtime logic is touched. The worst-case failure mode would be a build error or a minor codegen/perf difference, both of which CI would surface.

Level of scrutiny

Low. This is a small, mechanical build-config change following an established pattern — the same two flags are already passed on Linux/macOS/FreeBSD/Android per the PR description, and /clang: passthrough is already used elsewhere in this file (/clang:-masm=att). The COMPILER_IS_CLANG_CL guard variable is set in WebKitCommon.cmake well before the port options file is included, and is already used by other cmake files in this directory, so there is no ordering hazard.

Other factors

• The file header states it is only for clang-cl, so in practice the if (COMPILER_IS_CLANG_CL) branch is the one that will execute; the else() is a harmless no-op fallback preserving the original line.
• The block continues to use plain add_compile_options (not the MSVC_ADD_COMPILE_OPTIONS wrapper) as it did before, so no behavior change for non-C/CXX languages was introduced.
• The PR description shows the author verified the resulting -mframe-pointer= value with clang-cl -### on LLVM 19/21/22.
• No prior reviewer comments to address; the bug hunting system found nothing.