Non-Release clang builds fail under -Werror: the affected code is #if'd out in Release, which is all CI builds

Update: the GCC half of this report has since been addressed upstream by 5c635d5e50 ("build: scope -Werror to the Clang family so GCC builds again", #15701), which lands after this was filed. The GCC categories listed under "Scope" below are therefore no longer failures; they are kept only as evidence for the wider point, which still stands: the clang non-Release configurations remain unvalidated, and the two captures in PR #15749 still fail a clang Debug or RelWithDebInfo build.

Summary

Since #15660 turned every warning into an error, clang builds of any configuration other than Release fail. The CI matrix builds Release, and the code that fails does not exist in Release, so nothing in CI can see it.

Two instances exist on main today (a77209af8f):

src/slic3r/GUI/CameraPopup.cpp:85:56: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]
src/slic3r/GUI/StatusPanel.cpp:1465:56: error: lambda capture 'this' is not used [-Werror,-Wunused-lambda-capture]

Why CI cannot catch this class of break

Three things have to line up, and the third is the interesting one:

1. -Wunused-lambda-capture is clang-only. GCC does not implement it — g++ -Wunused-lambda-capture fails with unrecognized command-line option. On Linux, build_linux.sh uses GCC unless -l is passed, so a Linux contributor never sees it.
2. It became fatal rather than cosmetic with #15660's add_compile_options(-Werror).
3. Both call sites sit inside #if !BBL_RELEASE_TO_PUBLIC, and CMakeLists.txt:98 defines that as add_compile_definitions("BBL_RELEASE_TO_PUBLIC=$<CONFIG:Release>"). The block therefore compiles in Debug and RelWithDebInfo and not in Release — and Release is the only configuration CI builds.

So the configuration every local developer uses is the one configuration whose -Werror behaviour is unvalidated. A macOS contributor opening the project in Xcode gets Debug by default and the build fails; the same is true of ./build_linux.sh -el on Linux.

Reproduction

On main, with clang, any non-Release configuration:

cmake -S . -B build-dev -G "Ninja Multi-Config" \
  -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++
cmake --build build-dev --config RelWithDebInfo --target OrcaSlicer

Release in the same build directory succeeds.

Scope is probably larger than these two sites

The same reasoning applies to every #if !BBL_RELEASE_TO_PUBLIC block and to every warning category that only one compiler implements. As a data point from the other side of that gap: a GCC 16 build of main fails on 8 further categories that the clang census could not see — deprecated-declarations (Eigen's eulerAngles, CGAL's triangulate_hole), dangling-pointer, attributes, format-truncation, alloc-size-larger-than, range-loop-construct, unused-value, enum-compare. Those are all in Release, so they are a separate report, but they have the same root cause: the exception lists in CMakeLists.txt were censused against one compiler and one configuration.

Suggested direction

Beyond the two-line fix (PR to follow), a compile-only job in a non-Release configuration would close the gap permanently — it does not need to link or run, only to compile, since that is where -Werror bites.