Task: Implement Hotfix: silence the two gcc warnings in the generated domain.cpp

Table of Contents

This page documents a task in the Hotfix: Continuous Linux gcc jobs red on two constructs in the generated domain.cpp story. It captures the goal, current status, acceptance, and any notes or results.

1. Goal

The Continuous Linux gcc jobs fail in the generated parser at projects/ores.ore/core/src/domain/domain.cpp. Two gcc-only diagnostics stop the build. A case label falls through to the default label behind a // no break comment, and gcc 16 also reports a loop counter that is set but never read. Clang raises neither, so every clang job passes.

The file is emitted by xsdcpp and is never hand-edited. This task adds the two suppressions for that one file, under gcc only, beside the existing per-file suppressions in the component's CMakeLists.txt, and records the reason next to them. The gcc job can then reach the code that sits behind this error.

2. Status

Field Value
State DONE
Parent story Hotfix: Continuous Linux gcc jobs red on two constructs in the generated domain.cpp
Now Nothing.
Waiting on Nothing.
Next Nothing.
Last touched 2026-09-15

3. Acceptance

  • domain.cpp compiles clean under gcc with the tree's compiler flags, both warnings silenced and the object file produced.
  • Clang keeps the flags it had. The new flags sit behind a GNU-only guard, so the clang jobs are unaffected.
  • The code-class checks pass: full build and ctest on linux-clang-debug-make, the domain roundtrip check, the cmake-sources drift check, and the codegen drift check.
  • The generated file itself is unchanged. The diff holds one file, projects/ores.ore/core/src/CMakeLists.txt.

4. Plan

  1. Reproduce both diagnostics locally. Take the file's compile command from compile_commands.json, swap clang for gcc, drop the clang-only flags, and confirm the failure under the tree's own warning set.
  2. Probe the flag forms to pick the narrowest working fix. Test the comment markers, the [[fallthrough]]; attribute, and the flag spellings, and test them under both gcc and clang.
  3. Add the two flags to the per-file suppression list, under a GNU-only guard, with the reason in the comment above.
  4. Recompile the translation unit with the suppressions in place and confirm a clean object file.
  5. Run the code-class checks on the clang tree.
  6. Close the task and story bookkeeping, then raise one PR.

5. Notes

5.1. The failure

Continuous Linux on d780d75eeb, jobs linux-gcc debug and release: 

domain.cpp:435:13: error: this statement may fall through [-Werror=implicit-fallthrough=]
  435 |             if (context.pos.pos[1] == '>') {
domain.cpp:441:9: note: here
  441 |         default: // attribute or tag name

Both clang jobs passed on the same commit.

5.2. The compilers

Compiler Version Falls through Dead counter
CI gcc 13.3.0 warns silent
Local gcc 16.2.0 warns warns
Local clang 21.1.8 silent silent

5.3. The comment-form probe

Under gcc 16.2.0 with -Wall -Wextra -Werror: // no break warns. // fallthrough, // fall through, // FALLTHROUGH and [[fallthrough]]; are all clean. None of these fix the CI failure, because the file is generated. A hand edit to the comment would be lost at the next regeneration, and the attribute needs a change in xsdcpp, which lives outside this repository.

5.4. The flag-form probe

-Wno-implicit-fallthrough is clean. -Wno-implicit-fallthrough=0 still warns, so the bare form is the one to use. The flag works whether it sits before or after the file argument.

5.5. The second diagnostic

Local gcc 16.2.0 also reports domain.cpp:557: variable 'namespaceIndex' set but not used. It is a loop counter in setAttribute that is incremented and never read. CI's gcc 13.3.0 does not report it, but the flag is added now so that a later compiler bump does not turn the job red again for the same generated file.

5.6. Why the flags are GNU-only

Clang emits neither diagnostic, so scoping the flags to GNU keeps the clang job's warning set exactly as it was.

5.7. Local verification

The file's own compile command, taken from compile_commands.json, with clang++ swapped for g++, the clang-only flags dropped, and the two suppressions inserted before -o: 

exit=0
-rw-rw-r-- 1 marco marco 74877136 /tmp/fallthru/domain.cpp.o

No diagnostic of any kind. The object file is produced.

5.8. Open risk

No gcc run has been green since -Wall -Wextra landed on 2026-09-11. The last successful Continuous Linux run is 2026-09-08 (625f0ba0, run 2521), which predates those flags. Everything the gcc job compiled before ores.ore.core is clean, because the build reached domain.cpp. Nothing after it has been proved clean under gcc. Further gcc-only fallout may sit behind this error.

6. Test Scenarios

Manual QA scenarios (scaffolded via compass add test_scenario, run through the QA Validation Runner panel) that verify this task. Link new ones here as they're created; the scenario doc itself links back via its "Verifies task" field.

Scenario State Notes
     

7. PRs

PR Title
#2080 [ores.compass,ores.ore] Fix the red Continuous Windows and Linux gcc jobs

8. Review

Local review of the diff, per the code-review-pr pass.

# Finding File Decision Notes
1 -Wno-error=implicit-fallthrough would keep the diagnostic visible without failing the build, where the chosen flag hides it. CMakeLists.txt Declined The file cannot be edited, so the warning carries no action. The file's existing suppressions hide their diagnostics outright, so the new flags match the local convention. The chosen flag also silences the note that follows it.
2 -Wno-unused-but-set-variable suppresses a diagnostic CI's gcc 13.3.0 does not emit yet. CMakeLists.txt Accepted, deliberate Local gcc 16.2.0 does emit it on the same generated file. Adding the flag now stops the next CI image bump turning the job red again for the same generator defect.
3 Does the GNU branch also catch AppleClang, and change the macOS build? CMakeLists.txt No change needed CMAKE_CXX_COMPILER_ID is AppleClang, which the STREQUAL "GNU" test excludes, and which the outer =MATCHES "GNU Clang"= already covers as today. macOS keeps its current flags.
4 Do the per-file flags reach the compiler after -Wall -Wextra -Werror? CMakeLists.txt Verified The generated compile command for domain.cpp puts the source-level -Wno- list after the CMakeLists.txt flags, which is what makes the suppression effective.
5 Was the generated file touched? domain/domain.cpp No change needed The diff holds one file, CMakeLists.txt.
6 misspell check. all No change needed No hits in the changed paths. Two hits exist elsewhere in the tree (the update-ore-to-v17 task docs) and are outside this diff.

9. Result

The Continuous Linux gcc jobs can compile the generated parser again.

projects/ores.ore/core/src/CMakeLists.txt adds two flags to the per-file suppression list for domain.cpp, behind a GNU-only guard:

  • -Wno-implicit-fallthrough, for the case label that falls through to the default label behind a // no break comment.
  • -Wno-unused-but-set-variable, for the loop counter in setAttribute that gcc 16 reports as set but never read.

Both diagnostics come from xsdcpp, which lives outside this repository, so the generated file stays untouched. The clang jobs keep their flags, because the guard tests for GNU.

Local verification: the file's own command line, taken from compile_commands.json with g++ in place of clang++ and the two flags added, produced a 74877136-byte object file and no diagnostic of any kind. The gcc build itself reached and compiled the file with the suppressions in place, and raised no diagnostic for it, before the session harness stopped that build.

The code-class checks on the clang tree passed: the site build, the domain roundtrip check, the cmake-sources drift check, and the codegen drift check over the known-drift-free registry. The full local build did not finish, because the harness stopped it twice. Continuous Linux carries the proof for the whole tree, and the PR records what remains unproven.

Emacs 29.3 (Org mode 9.6.15)