-
Notifications
You must be signed in to change notification settings - Fork 6.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[vcpkg] Improve Json error messages #12981
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is the only thing I see that's easy to change. However, I have a lot of changes in #13038 that I don't particularly wish to merge with this, since they both make a lot of the same changes. I'd rather merge that one first because this is going to be easier to merge later.
Converting to draft until #13038 has been merged according to @strega-nil's preference |
dc7f840
to
21736c5
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a really great changeset :D
6796d7a
to
087fbe6
Compare
I reverted the line break change because it does not comply with our clang-format rules; if we want to change the rules I think it would be best to do it in another PR. |
Thanks for the reviews! |
* [vcpkg] Fix error reporting on json parse failure * [vcpkg] Track manifest path for use in diagnostics * [vcpkg] Use by-value for consumer API. Improve trailing comma diagnostic. * [vcpkg] Track errors directly inside Json::Reader * [vcpkg] Fixup use of .u8string() Co-authored-by: Robert Schumacher <roschuma@microsoft.com>
This PR improves error messages reported by the JSON parser; specifically when handling manifests.
This includes a fundamental shift away from the existing error approach taken by the CONTROL-file code because that approach is inappropriate for a JSON world. The CONTROL file format is specifically a very flat format, so explicitly printing a list of valid fields makes sense because there's only one context for fields[1].
JSON, on the other hand, is a fundamentally different beast with its hierarchical objects and arrays and therefore merits a different strategy. In this PR, I've approached the problem similar to compiler error messages which are better designed for a tree-based structure. Explaining the full possible schema in the error output would be extremely verbose, so instead I've opted to link users to the current best documentation (docs/specifications/manifests.md and docs/specifications/registries.md). When we have more polished docs for these file types, these links can be updated to point there.
To help users locate the errors within their files, I've opted to use a JSONPath-style location; potential future work would be to add source location tracking into the JSON nodes to enable proper "Go To Error" in editors such as Visual Studio Code.
As a drive by, this also fixes a regression in start-of-line tracking.
[1] Feature paragraphs are close enough to Source paragraphs that the valid field list is not great but still works.
Example 1:
Before:
After:
Example 2:
Before:
After:
Example 4:
Before:
After:
Example 5:
Before:
After:
Example 6 (
vcpkg-configuration.json
):Before:
After:
Example 7:
Before (Note: the valid field 'platform' is not listed anywhere in the list of valid fields):
After: