Add a natvis fallback visualizer for detail::json_default_base

[nlohmann]

Supersedes #4973 (which was based on an outdated develop and had conflicts) and fixes #4972. The template change is @sakuntalle's commit, kept with their authorship; thanks for the fix and for testing it in production for the past year!

What

For every ABI namespace, nlohmann_json.natvis now has a visualizer for json_default_base (the empty default base class of basic_json), under both of its names: json_default_base (current code, since #5238) and detail::json_default_base (3.12.0), with the same display and expansion rules as the basic_json<*> entry.

Why this works

With 3.12.0, Visual Studio 2022 shows nlohmann::json values as detail::json_default_base for some users, without any visualization. Natvis visualizers are inherited by derived types (Inheritable defaults to true). If no entry matches the most-derived type, the debugger uses the base class's visualizer, and it evaluates the expressions against the derived object. That's why m_data resolves even though json_default_base has no members.

Known gap

We still don't know why the basic_json<*> entry doesn't match in that setup. This PR adds a harmless fallback; it doesn't fix the root cause. If anyone can reproduce it, the output with Tools → Options → Debugging → Output Window → Natvis diagnostic messages set to Verbose would tell us.

Changes

• tools/generate_natvis/nlohmann_json.natvis.j2: new entries for {{ ns }}::json_default_base and {{ ns }}::detail::json_default_base, with a comment explaining the fallback.
• nlohmann_json.natvis: regenerated with tools/generate_natvis/generate_natvis.py --version 3.12.0. The file grows only by the new entries (two per ABI namespace). I checked that removing the new entries gives back exactly the previous file, and that the XML is well-formed.

This could not be tested in Visual Studio here (no Windows machine).

Breaking changes

No breaking changes. Only the debugger visualization file changes; the library code and public API are unchanged.

🤖 Generated with Claude Code

[nlohmann]

Review findings

1. The fallback names a type that no longer exists on develop (tools/generate_natvis/nlohmann_json.natvis.j2, the new <Type Name="{{ ns }}::detail::json_default_base">). Since Fix ADL leak of nlohmann::detail through basic_json's default base class #5238 (acf076a, which is part of this branch), json_default_base lives directly in the inline ABI namespace, not in detail (include/nlohmann/detail/json_custom_base_class.hpp:38). A small program built against this branch's include/ prints typeid of detail::json_base_class<void> as nlohmann::json_abi_v3_12_0::json_default_base. So none of the 129 new entries would match code built from current headers or any later release; they only match 3.12.0. Fixed in 1e50d65: the template now emits entries for both {{ ns }}::json_default_base (current code) and {{ ns }}::detail::json_default_base (3.12.0, the version in Natvis file for version 3.12.0 does not contain a type definition for detail::json_default_base #4972). The natvis is regenerated with generate_natvis.py --version 3.12.0. It matches the generator output byte for byte, and xmllint --noout reports well-formed XML.

2. The PR body describes the file growth wrongly. It says "The file grows because it now covers all ABI tag combinations present on develop." develop's nlohmann_json.natvis already covers all 128 ABI namespaces and matches the develop template byte for byte. The growth before this fix, 6845 − 3878 = 2967 lines = 129 × 23, came only from the new entries (this also agrees with the "removing the new entries gives back exactly the previous file" check, which I reproduced). I updated the PR body accordingly: the sentence is gone, and the What and Changes sections mention both type names.

Checked and fine: the committed natvis matched the generator output at 63c212b. The ABI tag order in generate_natvis.py matches NLOHMANN_JSON_ABI_TAGS in abi_macros.hpp. value_t is still in detail.

— posted by Claude Code on behalf of @nlohmann

[sakuntalle]

Hey! Glad that it's finally making it's way in the package! 💪

[nlohmann]

@sakuntalle Could you try the natvis file and/or review this PR?

[github-actions]

🔴 Amalgamation check failed! 🔴

The source code has not been amalgamated and/or formatted correctly, or BUILD.bazel is out of date.

📎 A ready-to-apply patch is attached to the failed workflow run as the amalgamation-patch artifact. Download it, then apply it locally from the repository root with:

git apply amalgamation.patch

This does not require installing astyle yourself.

[sakuntalle]

@sakuntalle Could you try the natvis file and/or review this PR?

Hey! Unfortunatelly I’m not part of that project anymore so I don’t have access to that codebase that was yielding the issue.
As for reviewing, I’ll need to remember those details from 1 year ago☺️ based on my initial PR. I’ll have a look one of these days

[github-actions]

🔴 Amalgamation check failed! 🔴

The source code has not been amalgamated and/or formatted correctly, or BUILD.bazel is out of date.

📎 A ready-to-apply patch is attached to the failed workflow run as the amalgamation-patch artifact. Download it, then apply it locally from the repository root with:

git apply amalgamation.patch

This does not require installing astyle yourself.