[jll63]

(Written by Claude Code, on behalf of @jll63.)

The troubleshooting page mixed three worked compilation errors, the runtime errors, and an index of every message. It now has a short intro, then a compile-time section, then a runtime section. Each is grouped by category, and every error sits under a heading that quotes its message, with a short example that produces it, the fix, and a link that opens the example on Compiler Explorer.

Compile-time

• 50 examples, each a compile_fail_*.cpp file under doc/modules/ROOT/examples/troubleshooting/. test/CMakeLists.txt and test/Jamfile already glob them, so in CMake each one is checked against the message it is filed under.
• They share preamble.hpp (includes, Node, Plus, my_registry), which the page shows once. The two existing examples now use it too.
• Examples that only fail on some setups emit the expected text with #error where they can't fail, as test/compile_fail_reflection_*.cpp already do:
  • the C++26 reflection ones, checked with g++-16 -freflection, where they hit the real assertions;
  • minimal_cover_hash in a translation unit without BMI2.
• Four messages have no example, and the page says why:
  • the two gcc-only follow-on messages, which only ever follow a more specific error;
  • the size_t/void* check, which depends on the platform;
  • the named_static_rtti check for __PRETTY_FUNCTION__/__FUNCSIG__, which depends on the compiler.
• Three examples call the method after the tagged region, because MSVC does not instantiate a method from its declaration alone; two runtime snippets strip the struct that MSVC writes before class names.

Runtime

New snippets, each checking the message on stderr:

• not implemented
• ambiguous
• not initialized
• final_virtual_ptr misuse
• conflicting definitions: two translation units that disagree on BOOST_OPENMETHOD_ENABLE_RUNTIME_CHECKS
• the minimal_perfect_hash and minimal_cover_hash search failures

Fixes

• Every entry ends with a Fix that corrects its example. A compile-time fix is troubleshooting/fix_<stem>.cpp, compiled as a test by test/CMakeLists.txt and test/Jamfile, so a fix that does not compile fails the build. A runtime fix is snippets/fix_<stem>.cpp, a Boost.Test program that checks the call now succeeds silently.
• Where an error can be fixed on either side - the overrider or the method, the parameter or the registry - the entry shows both, the second under Alternative fix with a sentence saying when to prefer it. Twenty entries have one, as fix_<stem>_2.cpp. For example, for different virtual_ptr<> pointer kinds, the method may take a shared_virtual_ptr instead.
• The page moves after the reference in the navigation.

Compiler Explorer links

• Each Example label links to the example on Compiler Explorer: the source above the compiler output - and the program output, for a runtime error - with no assembly. The ODR example needs two translation units and has no link.
• dev/ce_troubleshooting.py generates the links and rewrites them in place; run it whenever an example changes. A compile-time example becomes the preamble followed by the example file. A runtime snippet becomes a main() without the test harness, so the default error handler prints the message. The library comes from the flattened headers of develop published on boostorg.github.io, so the messages are those of develop, not of the Boost release that Compiler Explorer offers.
• dev/ce_troubleshooting.py --check compiles and runs every example through the Compiler Explorer API, and matches the output against the expected message.

Verification

• ctest: 276/276 pass (clang 22).
• b2 (clang 22): all the fixes compile. The one failure, implicit_shared_libraries/named_static_rtti, is unrelated: this branch touches no header and no test there.
• dev/ce_troubleshooting.py --check: all 60 linked examples produce their expected message on Compiler Explorer (clang 23.1, gcc 16.1 for reflection).
• Antora build: no warnings on the page; every anchor and reference link resolves.
• MSVC was not tested locally, and the fixes have not been compiled with it.

🤖 Generated with Claude Code

https://claude.ai/code/session_01958YRGfNfb6SfQS9v4hWTr

[cppalliance-bot]

An automated preview of the documentation is available at https://142.openmethod.prtest3.cppalliance.org/libs/openmethod/doc/html/index.html

If more commits are pushed to the pull request, the docs will rebuild at the same URL.

2026-11-12 13:57:41 UTC

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 92.57%. Comparing base (b681217) to head (e319d6c).
⚠️ Report is 27 commits behind head on develop.

Additional details and impacted files

@@           Coverage Diff            @@
##           develop     #142   +/-   ##
========================================
  Coverage    92.56%   92.57%           
========================================
  Files           29       29           
  Lines         2314     2316    +2     
  Branches       699      699           
========================================
+ Hits          2142     2144    +2     
  Misses         111      111           
  Partials        61       61           

---

Continue to review full report in Codecov by Harness.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update f535533...e319d6c. Read the comment docs.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.