From 3697d2c008f73a794e95ad237255560c9419c0fb Mon Sep 17 00:00:00 2001 From: Jean-Louis Leroy Date: Thu, 17 Sep 2026 19:05:50 -0400 Subject: [PATCH 1/2] doc: correct two stale notes in CLAUDE.md's registry-affinity section Both were falsified by changes that did not update the prose around them. #113 collapsed the "Two things deliberately do not participate" bullets into one sentence, because `use_classes` had just started participating - but then named two things under "One thing": the interop headers and the C++26 `register_classes`. Restore the bullet form for the two that are left. The same sentence says the `any` and `type_erasure` interop headers "are untouched". #116 touched all three of them, and had to: #113 gave `virtual_` a registry parameter, and their `validate_method_parameter` specializations still spelled `virtual_`, which after the change matches only the defaulted argument. What survives is the affinity claim, which is the point of the paragraph - a `virtual_any` contributes none. Say that, and record why a specialization there cannot go back to the bare spelling. The PCH paragraph names `test_capture_errors.hpp` as the only header that carries the override on a test's behalf. `test/CMakeLists.txt` has scanned for `test_checked_registry.hpp` as well since #93; the sentence three lines above, "do not add a fourth marker", already counts three. Co-Authored-By: Claude Opus 5 --- CLAUDE.md | 21 +++++++++++++-------- 1 file changed, 13 insertions(+), 8 deletions(-) diff --git a/CLAUDE.md b/CLAUDE.md index c2e7ee95..b797e968 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -553,11 +553,16 @@ default). Mixing a declaring class with a non-declaring one is an error, where t among a method's parameters is fine. `detail::class_list_registry` decides; `unanimous_registry` is the strict fold, deliberately *not* `agreed_registry`. -One thing deliberately does **not** participate, and is documented as such: the `any` and -`type_erasure` interop headers are untouched, and `virtual_any&` contributes no affinity, so -a method over one behaves exactly as before. The C++26 `register_classes` also still defaults to -the macro - its groups may name a namespace, whose classes are only known during the scan that the -choice of registry feeds. +Two things deliberately do **not** participate, and both are documented as such: + +- The `any` and `type_erasure` interop headers declare no affinity. `virtual_any&` + contributes none, so a method over one behaves exactly as before. They are not untouched, + though: #116 gave their `validate_method_parameter` specializations the registry parameter + `virtual_` gained in #113, so a parameter may still *spell* a registry + (`virtual_`) - a different thing from declaring an affinity, and the + reason a specialization there must never go back to the bare `virtual_` spelling. +- The C++26 `register_classes` still defaults to the macro - its groups may name a namespace, + whose classes are only known during the scan that the choice of registry feeds. **A test that selects a registry through an affinity needs no PCH marker.** The scan below exists because `BOOST_OPENMETHOD_DEFAULT_REGISTRY` must be defined before `core.hpp` is parsed, and a @@ -567,9 +572,9 @@ headers, so those tests can share the PCH - do not add a fourth marker for them. `test/CMakeLists.txt` withholds the shared PCH from any `test_*.cpp` that overrides the registry - a force-included PCH would still precede the `#define`. It detects them by scanning for the token `BOOST_OPENMETHOD_DEFAULT_REGISTRY` **or** for an include of a header that -carries the override on the file's behalf (`test_capture_errors.hpp`). Add another such header -and the scan has to learn about it: miss one and the file still compiles, binds to -`default_registry`, and fails at run time. +carries the override on the file's behalf (`test_capture_errors.hpp` and +`test_checked_registry.hpp`). Add another such header and the scan has to learn about it: miss +one and the file still compiles, binds to `default_registry`, and fails at run time. ### Flattened headers for Compiler Explorer From 4a1a726b5ede8e025e7605f9dc1e7099a434964e Mon Sep 17 00:00:00 2001 From: Jean-Louis Leroy Date: Thu, 17 Sep 2026 19:41:09 -0400 Subject: [PATCH 2/2] doc: state the rule against committing build output #103 merged 415 files of b2 output - 613 MiB expanded, 94 MiB in the pack, on a repository of about 3 MB - days after #108 added the `bin/` ignore rule intended to prevent it. The branch was cut before that rule landed, and an ignore rule does not apply to a path that is already tracked, so the merge carried them in. Nothing in the build or the review catches this, and #117 could only untrack them: the superproject pins this library by SHA and its bot bumps the pin within minutes of every merge, so rewriting `develop` orphans commits `boostorg/boost` already points at - and would not even remove the blobs, which stay reachable through `refs/pull//head`. Write the rule down where the workflow is: stage named paths, never `git add `, and ask before committing a build artefact or any file over 1MB. Co-Authored-By: Claude Opus 5 --- CLAUDE.md | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) diff --git a/CLAUDE.md b/CLAUDE.md index b797e968..b5c4c916 100644 --- a/CLAUDE.md +++ b/CLAUDE.md @@ -673,6 +673,30 @@ For examples: 4. For changes affecting examples: enable `BOOST_OPENMETHOD_BUILD_EXAMPLES` 5. Submit PRs against the `develop` branch +### Never commit build output, and ask before committing anything large + +Stage named paths. `git add ` and `git add -A` are not used here: b2's object trees (`bin/` +at the root and under `config/`, `test/`, `test/dynamic_loading/` and each +`test/implicit_shared_libraries/` variant) and CMake's `build/` sit in the working tree, and one +careless `git add test` commits them. **Ask before committing any build artefact, and before +committing any file over 1MB**, whatever its kind. + +`.gitignore` is not a safety net. It has no effect on a path that is already tracked, and a branch +cut before an ignore rule landed does not carry it - which is how #103 merged 415 files of b2 +output, 613 MiB expanded and 94 MiB in the pack on a repository of about 3 MB, days after #108 +added the `bin/` rule meant to prevent exactly that. + +On a Boost library the mistake is permanent, and rewriting `develop` is not a remedy: + +- The superproject pins `libs/openmethod` by SHA, and its bot bumps that pin within minutes of + every merge, so a rewrite orphans the commits `boostorg/boost` already points at - + `git submodule update` then fails at those commits for good. +- The blobs stay reachable through `refs/pull//head`, which a maintainer cannot delete, and + forks share object storage. Removing them for real is a GitHub Support matter. + +So the only cheap fix is `git rm -r --cached` (#117), which cleans the tree and leaves the objects +in the pack forever. Not committing them is the whole defence. + ### Posting in public on the maintainer's behalf Anything published under the maintainer's account - a GitHub issue or comment, a PR body, a