[veselink1]

Uses the provided allocator to allocate the stack used to avoid recursion in the destroy() implementation used by ~basic_json.

This addresses issue #4842, by changing the std::vector to use the user-provided allocatorl

[coveralls]

coverage: 99.19%. remained the same
when pulling ff3eaf8 on veselink1:develop
into d33ecd3 on nlohmann:develop.

[github-actions]

This pull request has been marked as stale because it has had no activity for 30 days. While we won’t close it automatically, we encourage you to update or comment if it is still relevant. Keeping pull requests active and up-to-date helps us review and merge changes more efficiently. Thank you for your contributions!

[nlohmann]

Please rebase to the latest develop branch to have a green CI.

[github-actions]

This pull request has been marked as stale because it has had no activity for 30 days. While we won’t close it automatically, we encourage you to update or comment if it is still relevant. Keeping pull requests active and up-to-date helps us review and merge changes more efficiently. Thank you for your contributions!

[github-actions]

This pull request has been marked as stale because it has had no activity for 30 days. While we won’t close it automatically, we encourage you to update or comment if it is still relevant. Keeping pull requests active and up-to-date helps us review and merge changes more efficiently. Thank you for your contributions!

[nlohmann]

Thanks a lot for the fix, @veselink1, and sorry this sat for so long. I merged the latest develop into your branch and added a regression test to unit-allocator.cpp. The test uses a counting allocator and checks that destroying a nested array or object allocates the temporary stack through it. It fails without your change and passes with it. Once CI is green, this is good to go.

_{This comment was written by Claude Code on behalf of @nlohmann.}

[gregmarr]

@nlohmann I wonder if any of the other temporary vectors added in the recent iterative cleanups should also use the provided allocator.

[nlohmann]

@gregmarr Good question, thanks! I went through them. Most of the new temporary vectors hold only pointers, iterators and counters: the copy worklist and the stacks for merging (#5547), hashing (#5546), dump() (#5285) and the binary readers (#5505). That's the same as the parser's ref_stack or the lexer's token_string, which have always used std::allocator.

The one exception is the deep copy's key scratch space from #5389. It holds std::pair<key_type, basic_json> values, so it should use the provided allocator just like the destructor's stack here. That's #5573, which also documents that AllocatorType allocates the JSON values while most temporary storage still uses std::allocator.

_{This comment was written by Claude Code on behalf of @nlohmann.}

[nlohmann]

@veselink1 Are you willing to complete this?

[nlohmann]

Thanks a lot for this fix, @veselink1! Since we didn't hear back, we continued in #5762. Your commit is included there with you as author. With the allocator in place, a failing allocator could make the destructor throw (#5135), so #5762 goes one step further and makes destruction completely allocation-free.

_{This comment was written by Claude Code on behalf of @nlohmann.}