This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Correctly escape newlines and backslashes in the JSON serializer
ClosedPublic

Authored by kubamracek on Jun 17 2017, 5:46 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

kubamracek created this revision.Jun 17 2017, 5:46 PM
joerg added a subscriber: joerg.Jun 17 2017, 5:55 PM

Please see the discussion in D31992. This patch seems to go in the wrong direction.

I see. The approach to escape as little as possible can be valid, I guess.

In any case, this patch seems to do exactly this. We must escape backslashes, otherwise we’ll produce invalid output: imagine a backslash at the end of the string. Same about newlines: there are parsers that will refuse unescaped newlines.

joerg added a comment.Jun 18 2017, 3:01 PM

My suggestion would be to just use the YAML writer for now and leave a comment to make it clear that this is really JSON only.

beanz edited edge metadata.Jun 19 2017, 9:25 AM

My suggestion would be to just use the YAML writer for now and leave a comment to make it clear that this is really JSON only.

Our YAML parser can parse JSON because YAML is a superset of JSON, but I don't believe the YAML writer supports writing out inline-style YAML which would be compatible with a JSON parser. That might make the LLVM YAML writer unsuitable for @kubamracek's use case.

joerg added a comment.Jun 19 2017, 9:30 AM

I don't disagree with you, but please see the referenced review for further details.

I do not want the amount of adhoc JSON encoders to grow further. The YAML encoder works fine for most of the things, but it is easier to review calls to it than it is to find other instances of adhoc JSON encoding.

beanz added a comment.Jun 19 2017, 9:39 AM

I get your perspective, but holding up this relatively small patch that fixes a bug in existing code on an architectural disagreement seems like excessive bike shedding. If we assume that JSON is required for the use case would you have Kuba write a full JSON parser in LLVM to satisfy your distaste over the fact that we have multiple JSON parsers already? That seems like an unreasonable request just to fix a few small bugs in existing code.

Fundamentally I think we probably should migrate toward having a single JSON parser implemented in LLVMSupport, but I don't think this is the patch review to pick that fight over.

Not parsers, encoders. Note that the escaping is not correct for control characters other than \n.

This revision is now accepted and ready to land.Jun 19 2017, 8:32 PM
This revision was automatically updated to reflect the committed changes.