fix required member check for described structs in parse_into

[Ramya-9353]

Repro: parse_into a described struct whose members are all required, from {"a": 1, "a": 2, "a": 3}. It reports success, and b and c keep whatever the caller's object held. Same for {"a": 2} as the second element of [{"a": 1, "b": 1, "c": "one"}, {"a": 2}] parsed into std::vector<X>.
Cause: activated_ counts values signalled rather than distinct members, and is never cleared, so a repeated key stands in for a missing one, and each object in a sequence starts from the previous object's count.
Fix: record which members have been set, and clear that record in on_object_begin, the way the sequence handler already clears its container in on_array_begin.

[cppalliance-bot]

An automated preview of the documentation is available at https://1182.json.prtest2.cppalliance.org/libs/json/doc/html/index.html

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

2026-08-08 07:38:54 UTC

[cppalliance-bot]

GCOVR code coverage report https://1182.json.prtest2.cppalliance.org/gcovr/index.html
LCOV code coverage report https://1182.json.prtest2.cppalliance.org/genhtml/index.html
Coverage Diff Report https://1182.json.prtest2.cppalliance.org/diff-report/index.html

Build time: 2026-08-08 07:54:45 UTC

[cppalliance-bot]

Benchmark test results. More info at https://benchmark.cppalliance.org/jsonbenchmarks-pullrequests/1182/pullrequest.html

[grisumbras]

I will have to think a bit about this one. I'm not sure we should check for this, because non-unique keys are explicitly discouraged by the RFC. On the other hand, I see the value this adds.

[grisumbras]

This should be an std::bitset instead.

[Ramya-9353]

Done, switched to std::bitset (and the include from to ). Suite still passes, 9666 assertions, 0 failures.

[Ramya-9353]

On the RFC point: fair, though the patch does not actually reject duplicate keys as such. A document with repeated keys still parses so long as every required member is supplied somewhere; a repeat just no longer counts as a second distinct member. The other half of the bug also triggers with entirely unique keys: [{"a": 1, "b": 1, "c": "one"}, {"a": 2}] into std::vector<X> was accepted with the second element's b and c never written, because activated_ carried over the first object's count. Same carryover reaches map values and nested struct members.

[cppalliance-bot]

Benchmark test results. More info at https://benchmark.cppalliance.org/jsonbenchmarks-pullrequests/1182/pullrequest.html