Improved validation error handling

[anweiss]

All errors are currently Box'ed with little actionable information. The library should provide for better error handling mechanisms for lexing, parsing and validation.

[anweiss]

This has mostly been addressed. Further refinements will be made to the validation error reporting.

[anweiss]

Re-opening as the library could use a re-write of the error handling mechanisms for both parsing and validation. Will likely leverage thiserror.

[anweiss]

Decided on https://github.com/yaahc/displaydoc due to its support for no_std.

[anweiss]

@tomachristian would love your input on how I can improve the error handling mechanisms in the validator. Some of this is still dependent on the ratification of JSONPath as a formal standard. It would also be good to get some of the community's input on how CDDL should be traversed for solid error reporting.

CC @cabo for input too

[cabo]

Which kinds of errors are you looking at?

• invalid CDDL (parse errors, group/type errors, ...)?
• validation failures (input does not match CDDL grammar)?

Right now, I'm very interested in the latter. The obvious implementation of validation leaves you with little clues ("Kernighan's car" -- just like a Prolog program that simply says "no"...). So how can the information about which paths were taken in a validation be presented? E.g., if a = b/c/d/e, which of the failures in that choice is the juicy one (or do you report all)?

[anweiss]

Thanks @cabo. Interested in the validation failures specifically. And yea, at the moment, this crate is just presenting all of the failures in the case of type choices where none of the options are valid. It would be good to have some sort of JSONPath-like mechanism for pin-pointing where in the CDDL the validation failure occurred.