段階的に -Werror 化してビルドを堅牢にする

[thawk105]

親イシュー: #29 関連
依存: #41 (P3) — ccbench_add_protocol() で警告フラグを target ごとに付けられる前提

概要

現状、本体ビルドは -Wall も -Wextra も付けていない (cmake/ProtocolHelpers.cmake:45-49 のコメント参照 → このセクションは Phase 1 で更新済み)。ccbench_add_protocol() には set_compile_options() を呼ぶフックがあるが、累積した既存 warning が大量にあって -Werror を一度に有効化するとビルドが落ちるため、P3 ではあえて無効のままにした。

このイシューでは、-W<flag> を 1 種類ずつ 段階的に潰し、最終的に set_compile_options() を ccbench_add_protocol() から呼べる状態 (-Wall -Wextra -Werror) にすることをゴールとする。

進捗 (2026-05-14 時点)

Phase	状態	PR
Phase 1 (真のバグ候補)	✅ 完了	#44, #47, #50
Phase 2 (型の取り扱いミス)	✅ 完了	#68, #69
Phase 3 (セマンティクス系)	✅ 完了	#54, #56
Phase 4 (cosmetic)	✅ 完了	#55, #58
Phase 5 (仕上げ)	⏳ 未着手	—

合計 9 PR がマージ済。ccbench_add_protocol() の target_compile_options に有効化済みの -Werror=... は 9 個:

target_compile_options(${target} PRIVATE
  -Werror=maybe-uninitialized      # Phase 1
  -Werror=unused-but-set-variable  # Phase 1
  -Werror=unused-label             # Phase 1
  -Werror=reorder                  # Phase 3
  -Werror=unused-parameter         # Phase 4
  -Werror=catch-value              # Phase 3
  -Werror=unused-variable          # Phase 4
  -Werror=ignored-qualifiers       # Phase 2
  -Werror=sign-compare)            # Phase 2

Phase 1〜4 のフラグ潰しはこれで完了。残るは Phase 5 (仕上げ) のみ。

現状の warning 集計 (Phase 2 着手前)

Werror なしでビルドして集めた結果 (重複箇所をユニーク化):

-W フラグ	ユニーク件数	危険度	状態
-Wmaybe-uninitialized	1 (+ GCC 13 で別 3 件)	🔴 高	✅ #44
-Wunused-but-set-variable	3	🟡 中	✅ #47
-Wunused-label	7	🟢 低	✅ #50
-Wignored-qualifiers	30	🟡 中	✅ #68
-Wcatch-value=	46	🟡 中	✅ #56
-Wreorder	52	🟡 中	✅ #54 (ユニーク 20 件確定)
-Wsign-compare	61	🟡 中	✅ #69
-Wunused-parameter	123	🟢 低	✅ #55 (ユニーク 21 箇所)
-Wunused-variable	167	🟢 低	✅ #58
合計	490		9/9 完了

ホットスポット (ファイル別ユニーク件数 top 5、Phase 2 着手前):

ファイル	件数
include/bomb.hh	137
include/bomb_pessimistic.hh	23
include/tpcc/tpcc_tx_orderstatus.hh	18
include/tpcc/tpcc_tx_delivery.hh	18
include/ycsb.hh	14

副次産物: 真のバグの表面化

「-Werror=cosmetic」だけと思っていた cleanup が、実際には複数の真のバグを表面化した。これがこのイシューのロードマップ全体の最大の収穫:

発見 PR	バグ	対応
#44 (内部)	cicada pre_ver, mocc threshold, silo LogRecord padding (GCC 13 限定)	同 PR 内で修正
#50 (-Wunused-label)	std:stringstream (コロン 1 つ抜け; std: がラベル扱い + ss2pl 経由の using namespace std; で偶然通る)	同 PR 内で修正
#55 (-Wunused-parameter)	cicada/mvto Tuple::init() の use-after-move + INLINE_VERSION_OPT=1 でデータロス	issue #57 で追跡 (未修正)
#58 (-Wunused-variable)	get_material_cost() の tx.read Status check 漏れ (CLAUDE.md の警告そのもの)	同 PR 内で修正
(副次副次) #58	5 protocol の DELETE-commit で remove_value() の Status を捨てる重複	issue #59 で追跡 (cosmetic refactor)

Phase 別の詳細

Phase 1 — 真のバグ候補 ✅ 完了

• -Wmaybe-uninitialized (1 件 + GCC 13 で 3 件) — #44
• -Wunused-but-set-variable (3 件) — #47
• -Wunused-label (7 件) — #50

Phase 2 — 型の取り扱いミス ✅ 完了

• -Wignored-qualifiers (30 件) — #68. 戻り値の const 等が捨てられている (bomb.hh に集中)
• -Wsign-compare (61 件) — #69. 符号付き／無し比較、境界バグの可能性

並列 worktree subagent で進め、PR #68 / #69 を本日いずれも master に merge 済み。これで Phase 2 完了。

Phase 3 — セマンティクス系 ✅ 完了

• -Wcatch-value= (46 件) — #56. catch (std::out_of_range e) 等 44+2 件を const T& に
• -Wreorder (52 件 / ユニーク 20 件確定) — #54. 各 protocol の TxExecutor + oze TxNode の member initializer を宣言順に整列

Phase 4 — cosmetic ✅ 完了

• -Wunused-parameter (123 件 / ユニーク 21 箇所) — #55. [[maybe_unused]] 13 + 引数名隠し 8 で対処。Tuple::init() の真のバグ発見 → cicada/mvto: Tuple::init() overload で TupleBody が use-after-move + INLINE_VERSION_OPT=1 でデータロス #57
• -Wunused-variable (167 件) — #58. 削除 / (void) 化 / [[maybe_unused]] で対処。get_material_cost() の Status check 漏れ修正 + 5 protocol DELETE 共通化提案 → DELETE-commit 5 protocol で remove_value() の Status 捨て分岐が重複 → MasstreeWrapper 側に void wrapper を追加して統一 #59

Phase 5 — 仕上げ ⏳ 未着手

Phase 2 完了済み。Phase 5 にすぐ着手できる状態。

• cmake/ProtocolHelpers.cmake の target_compile_options(... -Werror=...) 列を set_compile_options(${target}) の呼び出し に置き換える (-Wall -Wextra -Werror を有効化)
• ccbench_common ターゲットにも -Wall -Wextra -Werror を適用
• cc/silo/replay_test.exe にも適用
• #59 (remove_value() の void wrapper 化) を一緒に取り込むかは別途判断
• CI が緑であることを確認

完了条件

• ccbench_add_protocol() から set_compile_options() が呼ばれている
• ccbench_common と replay_test.exe も -Wall -Wextra -Werror
• CI 緑

備考

• 計測は Release + -DENABLE_SANITIZER=OFF で実施 (ASan 経由の追加 warning を除外したいため)。Debug+ASan ビルドだと __odr_asan 関連の追加情報が出るが内容は同等。
• third_party (masstree 等) からの warning は 0 件 — imported targets として効果的に隔離されている。
• ワークロード共通ヘッダ (include/bomb.hh 等) の修正は、複数プロトコル × 複数ワークロードに波及するので、各 PR で CI で全 34 バイナリのビルドが通ることを確認している。
• Werror promotion 系の作業は GCC 13 (CI と同じ) でローカル確認すること。GCC 11 (旧 devcontainer) では flow-sensitive 警告 (-Wmaybe-uninitialized 等) で false negative があり、oze: 未初期化 ScanRange union を修正 + -Werror=maybe-uninitialized を有効化 #44 で 3 ラウンド CI 往復した経緯あり。現在 devcontainer は ubuntu:24.04 = GCC 13 に揃えてある (devcontainer: Ubuntu 24.04 (GCC 13) に上げて CI と compiler を一致させる #45)。
• Phase 2 (-Wignored-qualifiers, -Wsign-compare) は 並列 worktree subagent で進めた。並列で出た PR Phase 2: -Wignored-qualifiers を潰して -Werror=ignored-qualifiers を有効化 #68 / Phase 2: -Wsign-compare を潰して -Werror=sign-compare を有効化 #69 の master tip との rebase 解消は親エージェントが担当した。

Related

• [構造監査] 新CCプロトコルを安全・低コストに追加できるよう基盤をリファクタリングする #29 (親)
• cicada/mvto: Tuple::init() overload で TupleBody が use-after-move + INLINE_VERSION_OPT=1 でデータロス #57 (Phase 4 で発見した cicada/mvto Tuple::init() の use-after-move バグ)
• DELETE-commit 5 protocol で remove_value() の Status 捨て分岐が重複 → MasstreeWrapper 側に void wrapper を追加して統一 #59 (Phase 4 で見えた remove_value() の共通化提案)