Better diagnostics

[nlohmann]

This PR improves the diagnostic information provided by the library in case of exceptions. The idea (originally described in #1508 (comment) and #932 (comment)) is that every JSON value in an array or object contains a pointer to the enclosing container. From this parent relation, we can generate a JSON Pointer to the current value that allows to identify the erroneous value. As we need to store one additional pointer per JSON value, the diagnostic mode is guarded by a preprocessor macro JSON_DIAGNOSTICS that needs to be defined in order to enable the better diagnostics.

This PR is work in progress. There are a lot of open tasks, including

• set the parent pointer in all situations
• find a way to deal with iterators
• add diagnostics to exceptions
• add tests
• add CMake option

Any help, input, review, or discussion is greatly appreciated!

Closes #1508. Closes #932. Closes #2552.

[coveralls]

Coverage remained the same at 100.0% when pulling 56a6dec on diagnostics into e754ef7 on develop.

[nlohmann]

Thanks @gregmarr for the comments! I will look at them in detail later this week.

[karzhenkov]

There is a missed point. The following assigment will be lost after the object is moved to the container:

json/include/nlohmann/json.hpp

Line 1646 in d4a91b7

(*element.m_value.array)[1].m_parent = this;

[nlohmann]

There is a missed point. The following assigment will be lost after the object is moved to the container:

json/include/nlohmann/json.hpp

Line 1646 in d4a91b7

(*element.m_value.array)[1].m_parent = this;

Unfortunately, I cannot create an example where the parent is lost.

Would you propose setting the parent after calling emplace?

[karzhenkov]

I think it can be done something like this: karzhenkov/json@22bd1e1

[nlohmann]

@gregmarr @karzhenkov I think this branch is ready now. Any further comment or observation?

[karzhenkov]

Here are also some proposals to undo unnecessary changes and make the code a bit more concise: karzhenkov#1

[nlohmann]

Here are also some proposals to undo unnecessary changes and make the code a bit more concise: karzhenkov#1

I took over some of your ideas: 74cc0ab. What do you think?

[karzhenkov]

It would also be nice to get rid of the empty json objects that are created in many places just to indicate "no diagnostics". This can be achieved with an overload of exception::diagnostics taking std::nullptr_t and with some defaults (BasicJsonType = std::nullptr_t; context = nullptr) here:

json/include/nlohmann/detail/exceptions.hpp

Lines 187 to 188 in 74cc0ab

	template<typename BasicJsonType>
	static parse_error create(int id_, const position_t& pos, const std::string& what_arg, const BasicJsonType& context)

Other similar function templates need the same defaults.

As a possible point of additional extension, we can also consider other types of context that may be appropriate if no relevant json object is available.

[gregmarr]

Ugh, started a review yesterday and forgot to submit it.

[gregmarr]

Can this just be {} instead of BasicJsonType()? (Not sure now what works in C++11 and what requires later versions.)

[gregmarr]

I'm assuming that you want to be explicit about not providing a json object here and so don't want a default parameter value.

[nlohmann]

I tried earlier to work with a default value, but I got an error that the type could not be derived. I'll give it another check later.

[gregmarr]

Ah, it's a templated parameter, yeah that makes it harder to have a default.

[gregmarr]

LGTM