Test JSON_BRACE_INIT_COPY_SEMANTICS for real, and fix one-element tuples under it

[nlohmann]

What & why

The opt-in JSON_BRACE_INIT_COPY_SEMANTICS (#5074, new in 3.13.0) has never been exercised by CI. There are two independent reasons, and either one is enough on its own:

1. The test compiled to nothing. Its only test, in tests/src/unit-regression3.cpp, was guarded by #if defined(JSON_BRACE_INIT_COPY_SEMANTICS) && (JSON_BRACE_INIT_COPY_SEMANTICS == 1) after #include <nlohmann/json.hpp>. But detail/macro_unscope.hpp #undefs the macro unconditionally (outside the JSON_TEST_KEEP_MACROS block), so the guard was false whatever -D flag was passed.
2. The CI target was never run. ci_test_brace_init_copy_semantics in cmake/ci.cmake passes -DJSON_BRACE_INIT_COPY_SEMANTICS=1, but no workflow names it.

The problem surfaced in #5534's review, while adding the next opt-in macro (JSON_STRICT_NUL_HANDLING), which already uses the right pattern.

The change

• A dedicated test file. tests/src/unit-brace-init-copy-semantics.cpp defines the macro before including the header, as unit-diagnostics.cpp does for JSON_DIAGNOSTICS. The glob picks it up, so it runs in every CI job and for every standard. Each unit test is its own executable, and test_main does not include the header, so no program mixes the two settings. The old test case moved here, and the dead block in unit-regression3.cpp is gone.

• The unused target is removed. It ran the whole suite with the macro on. That suite deliberately encodes the default semantics in about 90 places (json({1}) meaning [1], json patch = {{{"op", ...}}}, const json j = {9};), so it could never have passed. Rewriting those would test nothing new.

• A library bug the macro exposed. Running the whole suite with the macro on is how I found which of those failures were the library's own. Exactly one was: to_json for std::tuple builds j = { std::get<Idx>(t)... }, so with copy semantics a one-element tuple became its element:

  #define JSON_BRACE_INIT_COPY_SEMANTICS 1
  json j = std::tuple<int>{5};   // before: 5, after: [5]
  j.get<std::tuple<int>>();      // before: throws type_error.302

  Under the macro, a one-element tuple now builds exactly what the default deduction builds: [x], or an object when x is a [string, value] pair, as it always has been. Without the macro the code path is unchanged.

• The new test pins the macro's scope. Besides what the macro changes, it checks what it must not change. Those are lists with more than one element; a single [string, value] pair, which still becomes an object; json::array(); and the library's conversions: one-element tuples, vectors, arrays, lists and maps, std::pair, and items(). That section was also run with the macro forced to 0, where it passes unchanged. Against develop's header, the tuple checks fail as described above.

• An ABI tag for the macro. It changes the initializer-list constructor and (with this PR) adds a to_json overload, both with the same mangled names in either mode, so mixing translation units compiled with and without it was an ODR violation. The macro is now encoded in the inline namespace as _bics, like JSON_USE_LEGACY_DISCARDED_VALUE_COMPARISON is as _ldvcmp. Its default moved to abi_macros.hpp so that json_fwd.hpp agrees. The ABI config tests, the new unit test, and the natvis generator know the tag (the generator also gained the missing _dp).

• Docs. The macro page now says that any single-element list is affected (json j = {1} is 1, json j = {{1, 2}} is [1,2]). The previous examples only showed a JSON object in braces. The namespace page now lists the macro's ABI tag (and the missing _dp tag of JSON_DIAGNOSTIC_POSITIONS).

Public API impact

No breaking changes. Default builds are byte-for-byte unaffected: the new overload only exists when JSON_BRACE_INIT_COPY_SEMANTICS is 1. For builds that opt in, one-element std::tuples serialize as they do without the macro. Builds that opt in also get the inline namespace nlohmann::json_abi_bics_v… instead of nlohmann::json_abi_v…. The macro is new in the unreleased 3.13.0, so this corrects it before it ships.

Verification

• The new test passes in C++11, 14, 17, 20 and 23. It is clean under -Wall -Wextra -Wpedantic -Werror, and under the project's -Weverything set except for warnings from the vendored doctest.h.
• Against develop's header, 5 of its 37 assertions fail: exactly the tuple checks.
• make amalgamate and make check-amalgamation pass.

---

• The changes are described in detail, both the what and why.
• If applicable, an existing issue is referenced. (Copy constructor changes semantics #5074, Document that a NUL byte in the input is treated as end of input #5534)
• The Code coverage remained at 100%. A test case for every new line of code.
• If applicable, the documentation is updated.
• The source code is amalgamated by running make amalgamate.

🤖 Generated with Claude Code