[clang-format] Add basic support for formatting JSON

[MyDeveloperDay]

Summary

I find as I develop I'm moving between many different languages C++,C#,JavaScript all the time. As I move between the file types I like to keep clang-format as my formatting tool of choice. (hence why I initially added C# support in D58404: [clang-format] Add basic support for formatting C# files) I know those other languages have their own tools but I have to learn them all, and I have to work out how to configure them, and they may or may not have integration into my IDE or my source code integration.

I am increasingly finding that I'm editing additional JSON files as part of my daily work and my editor and git commit hooks are just not setup to go and run jq, So I tend to go to JSON Formatter and copy and paste back and forth. To get nicely formatted JSON. This is a painful process and I'd like a new one that causes me much less friction.

This has come up from time to time:

D10543: clang-format: [JS] recognize .ts and .json in git-clang-format.
https://stackoverflow.com/questions/35856565/clang-format-a-json-file
https://bugs.llvm.org/show_bug.cgi?id=18699

I would like to stop having to do that and have formatting JSON as a first class clang-format support Language (even if it has minimal style settings at present).

This revision adds support for formatting JSON using the inbuilt JSON serialization library of LLVM, With limited control at present only over the indentation level

This adds an additional Language into the .clang-format file to separate the settings from your other supported languages.

-- 
Language: Json
IndentWidth: 2

For example of it working, this snipped from the Wikipedia definition of JSON can be formatted as below without the need to trick clang-format into thinking this is javascript:

file.json

{ "firstName": "John", "lastName": "Smith", "isAlive": true, "age": 27, "address": { "streetAddress": "21 2nd Street", "city": "New York", "state": "NY", "postalCode": "10021-3100" }, "phoneNumbers": [ { "type": "home", "number": "212 555-1234" }, { "type": "office", "number": "646 555-4567" } ], "children": [], "spouse": null }

$ clang-format.exe file.json
{
  "address": {
    "city": "New York",
    "postalCode": "10021-3100",
    "state": "NY",
    "streetAddress": "21 2nd Street"
  },
  "age": 27,
  "children": [],
  "firstName": "John",
  "isAlive": true,
  "lastName": "Smith",
  "phoneNumbers": [
    {
      "number": "212 555-1234",
      "type": "home"
    },
    {
      "number": "646 555-4567",
      "type": "office"
    }
  ],
  "spouse": null
}

[curdeius]

Why not using clang-format's support for JavaScript? It seems more complicated now, but it will probably allow to more easily change/add style options. WDYT?
And what happens when reformatting only a part of a JSON? Should there be some tests for that?

[MyDeveloperDay]

In D93528#2462723, @curdeius wrote:

Why not using clang-format's support for JavaScript? It seems more complicated now, but it will probably allow to more easily change/add style options. WDYT?
And what happens when reformatting only a part of a JSON? Should there be some tests for that?

I've attempted to do this via JavaScript before and failed ;-( and had to abandoned the attempt. This is partially because clang-format isn't very good at even handling any braced initialization (let alone nested initialization) and it made the code much more complex. (my guess is that is why it was never attempted before by others before)

So I decided to reset my expectations first, My intent here is to introduce the concept of JSON Language support (to gauge if adding JSON support is something the community might accept), but also to let me build the infrastructure that means we have some support which we know will work out of the box (at least to give us clean JSON full file formatting formatting)

Ultimately the JSON pretty printing in the Support library cannot really handle what realistically might be wanted i.e. ideally I'd like to support different positioning types for the {

[
    "name": {
         "bar": 1 
    },
    "name": {
         "foo": 2
    }
]

This first revision handles some basic concepts, introduction of the JSON support and full file formatting (to a compatible LLVM Style as defined by its own JSON library) + allowing setting different IndentWidths

Ultimately once we have this support, which I think is a necessity, we can switch the underlying formatting to support, partial formatting (as we would see via git clang-format) and the potential other options we'd like to support (which I consider we'd most likely handle inside reformat using tokens as you are suggesting).

So I guess my question is:

1. is this useful to pursue (either as is, or by switching to us the reformat method)
2. is this useful standalone as the first pass
3. is adding support for JSON something people would welcome (as we did with C#)

If the answer is no, then I don't want to waste the effort trying to fathom how we might do this inside reformat.

And what happens when reformatting only a part of a JSON? Should there be some tests for that?

Ultimately yes, but I don't think I can easily do that with the llvm/Support code, so that would need to be integrated into the refomat() (and this is why I didn't include a change into git-clang-format or clang-format-diff.py)

[HazardyKnusperkeks]

In D93528#2462969, @MyDeveloperDay wrote:

So I guess my question is:

1. is this useful to pursue (either as is, or by switching to us the reformat method)
2. is this useful standalone as the first pass
3. is adding support for JSON something people would welcome (as we did with C#)

If the answer is no, then I don't want to waste the effort trying to fathom how we might do this inside reformat.

For me that's three times yes.

clang/unittests/Format/FormatTestJson.cpp

14

I don't know what's the practice right now. But I would suggest renaming that to "format-test-json", so you can see directly that's for JSON.

[curdeius]

In D93528#2463030, @HazardyKnusperkeks wrote:

In D93528#2462969, @MyDeveloperDay wrote:

So I guess my question is:

1. is this useful to pursue (either as is, or by switching to us the reformat method)
2. is this useful standalone as the first pass
3. is adding support for JSON something people would welcome (as we did with C#)

If the answer is no, then I don't want to waste the effort trying to fathom how we might do this inside reformat.

For me that's three times yes.

For me as well. I believe it's a useful addition, even if it handles only the basic cases for the moment.
I was just wondering whether it would be better to start a different way, but I understand that implementing it the "clang-format's way" can take some effort.

Anyway, I'd like to see a big warning banner (somewhere in the doc) about current limitations, so that nobody switches hastily to clang-format and then gets disappointed by these limitations.
Not sure that having a small note about it in release notes is enough.
So to the point, please document that only full-context/file is supported and that the only formatting option is indentation level (as you partially did in release notes).

clang/docs/ReleaseNotes.rst

284

Maybe instead of putting "with very limited options", you may add a link to the doc describing limitations?

[sammccall]

In theory, this version doesn't seem so useful - a simple JSON pretty-printer that ignores column widths etc is easy to write, doesn't need any of clang-format's infrastructure, and this isn't a particularly great one.

In practice though, not having to configure yet another tool is a big deal:

my editor and git commit hooks are just not setup to go and run jq

+1, this is often the difference between using a mediocre tool and nothing.

And I think for JSON data, a formulaic pretty-printer is maybe a better starting point than clang-format's context-sensitive optimizing approach.

---

But we'll have to deal with the fact that this isn't going to format the way all people like. It seems reasonable to to expect to be able to:

• format ["foo"] on one line
• indent with tab characters rather than spaces
• format "JSON" that is incomplete/broken/has extensions (see JSON5)

With my maintainer-of-Support/JSON hat on, I don't like the idea of these features being shoehorned into the library to make clang-format an incrementally more featureful JSON formatter. They're likely to lead to a lot of conceptual+implementation+API complexity in a library that solves its primary use cases quite well and simply.

---

So if the plan is to

• use this implementation to bootstrap JSON-in-clang-format
• with a firm intention of replacing it with parsing/formatting logic that lives inside clang-format itself
• long-term, maybe making use of Support/JSON long-term for some low level bits (normalizing string tokens?) but not where flexibility is needed

then I think this is great. However I'm a bit leery if the plan is "land this a MVP, and then play it by ear".

[MyDeveloperDay]

With my maintainer-of-Support/JSON hat on, I don't like the idea of these features being shoehorned into the library to make clang-format an incrementally more featureful JSON formatter. They're likely to lead to a lot of conceptual+implementation+API complexity in a library that solves its primary use cases quite well and simply.

No plans at all to touch Support/JSON, if this needed a separate reformat() for json then I'd say I'm more likely to do that in lib/Format as we'd only need a "PrettyPrint" type function which supported the options we want to support

So if the plan is to

• use this implementation to bootstrap JSON-in-clang-format

That was kind of the plan

• with a firm intention of replacing it with parsing/formatting logic that lives inside clang-format itself

So I tried again to do this yesterday, but once again seems to fail, mainly around the area of clang-formatting trying to reflow and rejoin split lines but also the level of indentation is off.

I'm starting to wonder if perhaps it needs its own separate pass, use more of clang-format but less of the actual "parsing into known structures"...

• long-term, maybe making use of Support/JSON long-term for some low level bits (normalizing string tokens?) but not where flexibility is needed

I think I'd really just like to use the FormatTokens, but I agree if we ended up writing a specific JSON pretty-printer I could see using the inner parts (but I really have no interesting in touching lib/Support/JSON at all)

then I think this is great. However I'm a bit leery if the plan is "land this a MVP, and then play it by ear".

Sorry I'm not sure I understand what MVP means in this context?

clang/unittests/Format/FormatTestJson.cpp

14

I'm not sure of the convention or even where/when its used (I just know you need it)

lets take that change offline, we should either change them all or none of the them.

FormatTest.cpp:#define DEBUG_TYPE "format-test"
FormatTestCSharp.cpp:#define DEBUG_TYPE "format-test"
FormatTestComments.cpp:#define DEBUG_TYPE "format-test"
FormatTestJS.cpp:#define DEBUG_TYPE "format-test"
FormatTestJava.cpp:#define DEBUG_TYPE "format-test"
FormatTestJson.cpp:#define DEBUG_TYPE "format-test"
FormatTestObjC.cpp:#define DEBUG_TYPE "format-test"
FormatTestProto.cpp:#define DEBUG_TYPE "format-test"
FormatTestRawStrings.cpp:#define DEBUG_TYPE "format-test"
FormatTestSelective.cpp:#define DEBUG_TYPE "format-test"
FormatTestTableGen.cpp:#define DEBUG_TYPE "format-test"
FormatTestTextProto.cpp:#define DEBUG_TYPE "format-test"
NamespaceEndCommentsFixerTest.cpp:#define DEBUG_TYPE "namespace-end-comments-fixer-test"
SortImportsTestJS.cpp:#define DEBUG_TYPE "format-test"
SortImportsTestJava.cpp:#define DEBUG_TYPE "format-test"
SortIncludesTest.cpp:#define DEBUG_TYPE "format-test"
UsingDeclarationsSorterTest.cpp:#define DEBUG_TYPE "using-declarations-sorter-test"

[MyDeveloperDay]

I have reworked this patch to utilise the fact that clang-format can format a JSON object in javascript reasonably well.

This technique adds for JSON files only a replacement to the front of the JSON transforming:

{
    "A": 1,
    "B": [ 2,3 ]
}

into

x = {
    "A": 1,
    "B": [ 2,3 ]
}

This is then parsed by clang-format the a more traditional sense, allowing a similar technique as would be used when formatting the code, (but with some JSON specific rules, to make it follow primarily the style used by https://github.com/kapilratnani/JSON-Viewer (Notepad++ plugin, which at least I've used extensively)

After formatting, a subsequent replacement is merged to remove the x = from the front of the json, rendering it back to its original form.

{
    "A": 1,
    "B": [ 2,3 ]
}

I prefer to use this approach rather than our Support/JSON libraries which aren't really setup for formatting options, this give us greater flexibility later on if users want custom rules from brace wrapping.

[MyDeveloperDay]

Missing new test file

[MyDeveloperDay]

JSON strings can't be split when the line is too long like c++ strings

[HazardyKnusperkeks]

Nice trick! :)

[MyDeveloperDay]

Ensure git clang-format can handle json

[MyDeveloperDay]

Add more unit tests and ensure clang-format-diff is setup to check json

[MyDeveloperDay]

something @sammccall said about support foo["name"] made me realise that our javascript support doesn't always support what all the options

x = {
  "firstName" : "John",
  "lastName" : "Smith",
  "isAlive" : true,
  "age" : 27,
  "address" : {
    "streetAddress" : "21 2nd Street",
    "city" : "New York",
    "state" : "NY",
    "postalCode" : "10021-3100"
  },
  "phoneNumbers" : [
    {
      "type" : "home",
      "number" : "212 555-1234",
      "address" : "10 long address line, special road to nowhere",
    },
    {"type" : "office", "number" : "646 555-4567"}
  ],
  "children" : [],
  "children" : [ "foo", "bar" ],
  "children" : [ "foo" ],
  "children" : {},
  "spouse" : null
}

with

Language:        JavaScript
BasedOnStyle:  LLVM
SpaceInEmptyBlock: true
SpacesInSquareBrackets: false

made me think it should have been

"children" : ["foo","bar"],
"children" : ["foo"],
"children" : { },

it seems perhaps that ensuring javascript supports these would likely given JSON some of the style capabilities that people might want.

[MyDeveloperDay]

• Add release note
• Add default Column Limit of 0 for default Json Style (add unit test to ensure column limits can still be used)
  • this minimises the differences between what Notepad++'s JSON Format plugin (https://github.com/kapilratnani/JSON-Viewer) and clang-format produces

[MyDeveloperDay]

clang/docs/ReleaseNotes.rst

284

This new strategy actually gives us lots of pre-existing options, for example:

using TabWidth and UseTab we can tabify/de-tabify the json

using SpacesInContainerLiterals we can control if the json is ["foo"] or [ "foo" ]

Any option that can be used to format the javascript:

x = { ... }

can be used to format the JSON, I believe this gives us the best of both worlds, and some flexibility for the future if people want to format JSON in a specific BraceWrapping style.

[MyDeveloperDay]

@HazardyKnusperkeks thank you for the accept, if there are no objections from @curdeius , @krasimir and @sammccall I'd like to proceed.

[MyDeveloperDay]

ping, if there are no other opinions I plan to land this sometime this weekend.

clang/docs/ClangFormat.rst

 ===========
 ClangFormat
 ===========
 
 `ClangFormat` describes a set of tools that are built on top of
 :doc:`LibFormat`. It can support your workflow in a variety of ways including a
 standalone tool and editor integrations.
 
 
 Standalone Tool
 ===============
 
 :program:`clang-format` is located in `clang/tools/clang-format` and can be used
-to format C/C++/Java/JavaScript/Objective-C/Protobuf/C# code.
+to format C/C++/Java/JavaScript/JSON/Objective-C/Protobuf/C# code.
 
 .. code-block:: console
 
   $ clang-format -help
-  OVERVIEW: A tool to format C/C++/Java/JavaScript/Objective-C/Protobuf/C# code.
+  OVERVIEW: A tool to format C/C++/Java/JavaScript/JSON/Objective-C/Protobuf/C# code.
 
   If no arguments are specified, it formats the code from standard input
   and writes the result to the standard output.
   If <file>s are given, it reformats the files. If -i is specified
   together with <file>s, the files are edited in-place. Otherwise, the
   result is written to the standard output.
 
   USAGE: clang-format [options] [<file> ...]

clang/docs/ClangFormatStyleOptions.rst

* ``LK_CSharp`` (in configuration: ``CSharp``)
     Should be used for C#.
 
   * ``LK_Java`` (in configuration: ``Java``)
     Should be used for Java.
 
   * ``LK_JavaScript`` (in configuration: ``JavaScript``)
     Should be used for JavaScript.
 
+  * ``LK_Json`` (in configuration: ``Json``)
+    Should be used for JSON.
+
   * ``LK_ObjC`` (in configuration: ``ObjC``)
     Should be used for Objective-C, Objective-C++.
 
   * ``LK_Proto`` (in configuration: ``Proto``)
     Should be used for Protocol Buffers
     (https://developers.google.com/protocol-buffers/).
 
   * ``LK_TableGen`` (in configuration: ``TableGen``)

clang/docs/ReleaseNotes.rst

- Experimental Support in clang-format for concepts has been improved, to
   aid this the follow options have been added
 
 - Option ``IndentRequires`` has been added to indent the ``requires`` keyword
   in templates.
 - Option ``BreakBeforeConceptDeclarations`` has been added to aid the formatting of concepts.
 
 - Option ``IndentPragmas`` has been added to allow #pragma to indented with the current scope level. This is especially useful when using #pragma to mark OpenMP sections of code.
 
+- Basic Support has been adding for Formatting .json files (with very limited options)
+
 
 libclang
 --------
 
 - ...
 
 Static Analyzer
 ---------------

clang/include/clang/Format/Format.h

enum LanguageKind {
     /// Should be used for C, C++.
     LK_Cpp,
     /// Should be used for C#.
     LK_CSharp,
     /// Should be used for Java.
     LK_Java,
     /// Should be used for JavaScript.
     LK_JavaScript,
+    /// Should be used for JSON.
+    LK_Json,
     /// Should be used for Objective-C, Objective-C++.
     LK_ObjC,
     /// Should be used for Protocol Buffers
     /// (https://developers.google.com/protocol-buffers/).
     LK_Proto,
     /// Should be used for TableGen code.
     LK_TableGen,
     /// Should be used for Protocol Buffer messages in text format
     /// (https://developers.google.com/protocol-buffers/).
     LK_TextProto
   };
   bool isCpp() const { return Language == LK_Cpp || Language == LK_ObjC; }
   bool isCSharp() const { return Language == LK_CSharp; }
+  bool isJson() const { return Language == LK_Json; }
 
   /// Language, this format style is targeted at.
   LanguageKind Language;
 
   /// A regular expression matching macros that start a block.
   /// \code
   ///    # With:
   ///    MacroBlockBegin: "^NS_MAP_BEGIN|\
inline StringRef getLanguageName(FormatStyle::LanguageKind Language) {
   case FormatStyle::LK_CSharp:
     return "CSharp";
   case FormatStyle::LK_ObjC:
     return "Objective-C";
   case FormatStyle::LK_Java:
     return "Java";
   case FormatStyle::LK_JavaScript:
     return "JavaScript";
+  case FormatStyle::LK_Json:
+    return "Json";
   case FormatStyle::LK_Proto:
     return "Proto";
   case FormatStyle::LK_TableGen:
     return "TableGen";
   case FormatStyle::LK_TextProto:
     return "TextProto";
   default:
     return "Unknown";

clang/lib/Format/Format.cpp

 #include "clang/Basic/DiagnosticOptions.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Lex/Lexer.h"
 #include "clang/Tooling/Inclusions/HeaderIncludes.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringRef.h"
 #include "llvm/Support/Allocator.h"
 #include "llvm/Support/Debug.h"
+#include "llvm/Support/FormatVariadic.h"
+#include "llvm/Support/JSON.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/Regex.h"
 #include "llvm/Support/VirtualFileSystem.h"
 #include "llvm/Support/YAMLTraits.h"
 #include <algorithm>
 #include <memory>
 #include <mutex>
 #include <string>
static void enumeration(IO &IO, FormatStyle::LanguageKind &Value) {
     IO.enumCase(Value, "Cpp", FormatStyle::LK_Cpp);
     IO.enumCase(Value, "Java", FormatStyle::LK_Java);
     IO.enumCase(Value, "JavaScript", FormatStyle::LK_JavaScript);
     IO.enumCase(Value, "ObjC", FormatStyle::LK_ObjC);
     IO.enumCase(Value, "Proto", FormatStyle::LK_Proto);
     IO.enumCase(Value, "TableGen", FormatStyle::LK_TableGen);
     IO.enumCase(Value, "TextProto", FormatStyle::LK_TextProto);
     IO.enumCase(Value, "CSharp", FormatStyle::LK_CSharp);
+    IO.enumCase(Value, "Json", FormatStyle::LK_Json);
   }
 };
 
 template <> struct ScalarEnumerationTraits<FormatStyle::LanguageStandard> {
   static void enumeration(IO &IO, FormatStyle::LanguageStandard &Value) {
     IO.enumCase(Value, "c++03", FormatStyle::LS_Cpp03);
     IO.enumCase(Value, "C++03", FormatStyle::LS_Cpp03); // Legacy alias
     IO.enumCase(Value, "Cpp03", FormatStyle::LS_Cpp03); // Legacy alias
reformat(const FormatStyle &Style, StringRef Code,
   FormatStyle Expanded = expandPresets(Style);
   if (Expanded.DisableFormat)
     return {tooling::Replacements(), 0};
   if (isLikelyXml(Code))
     return {tooling::Replacements(), 0};
   if (Expanded.Language == FormatStyle::LK_JavaScript && isMpegTS(Code))
     return {tooling::Replacements(), 0};
 
+  if (Style.isJson()) {
+    Expected<llvm::json::Value> json = llvm::json::parse(Code);
+    if (!!json) {
+      std::string Format = "{0:" + llvm::Twine(Style.IndentWidth).str() + "}";
+      std::string NewCode = llvm::formatv(Format.c_str(), json.get());
+      tooling::Replacements replacements;
+      tooling::Replacement replacement(FileName, 0, Code.size(), NewCode);
+      if (!!replacements.add(replacement)) {
+        return {replacements, 0};
+      }
+      return {replacements, 0};
+    }
+  }
+
   typedef std::function<std::pair<tooling::Replacements, unsigned>(
       const Environment &)>
       AnalyzerPass;
   SmallVector<AnalyzerPass, 4> Passes;
 
   if (Style.Language == FormatStyle::LK_Cpp) {
     if (Style.FixNamespaceComments)
       Passes.emplace_back([&](const Environment &Env) {
if (FileName.endswith_lower(".textpb") ||
       FileName.endswith_lower(".pb.txt") ||
       FileName.endswith_lower(".textproto") ||
       FileName.endswith_lower(".asciipb"))
     return FormatStyle::LK_TextProto;
   if (FileName.endswith_lower(".td"))
     return FormatStyle::LK_TableGen;
   if (FileName.endswith_lower(".cs"))
     return FormatStyle::LK_CSharp;
+  if (FileName.endswith_lower(".json"))
+    return FormatStyle::LK_Json;
   return FormatStyle::LK_Cpp;
 }
 
 FormatStyle::LanguageKind guessLanguage(StringRef FileName, StringRef Code) {
   const auto GuessedLanguage = getLanguageByFileName(FileName);
   if (GuessedLanguage == FormatStyle::LK_Cpp) {
     auto Extension = llvm::sys::path::extension(FileName);
     // If there's no file extension (or it's .h), we need to check the contents

clang/tools/clang-format/ClangFormat.cpp

 int main(int argc, const char **argv) {
   llvm::InitLLVM X(argc, argv);
 
   cl::HideUnrelatedOptions(ClangFormatCategory);
 
   cl::SetVersionPrinter(PrintVersion);
   cl::ParseCommandLineOptions(
       argc, argv,
-      "A tool to format C/C++/Java/JavaScript/Objective-C/Protobuf/C# code.\n\n"
+      "A tool to format C/C++/Java/JavaScript/JSON/Objective-C/Protobuf/C# "
+      "code.\n\n"
       "If no arguments are specified, it formats the code from standard input\n"
       "and writes the result to the standard output.\n"
       "If <file>s are given, it reformats the files. If -i is specified\n"
       "together with <file>s, the files are edited in-place. Otherwise, the\n"
       "result is written to the standard output.\n");
 
   if (Help) {
     cl::PrintHelpMessage();

clang/unittests/Format/CMakeLists.txt

 set(LLVM_LINK_COMPONENTS
   Support
   )
 
 add_clang_unittest(FormatTests
   CleanupTest.cpp
   FormatTest.cpp
   FormatTestComments.cpp
   FormatTestCSharp.cpp
   FormatTestJS.cpp
   FormatTestJava.cpp
+  FormatTestJson.cpp
   FormatTestObjC.cpp
   FormatTestProto.cpp
   FormatTestRawStrings.cpp
   FormatTestSelective.cpp
   FormatTestTableGen.cpp
   FormatTestTextProto.cpp
   MacroExpanderTest.cpp
   NamespaceEndCommentsFixerTest.cpp

clang/unittests/Format/FormatTestJson.cpp

+//===- unittest/Format/FormatTestJson.cpp - Formatting tests for Json     -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===----------------------------------------------------------------------===//
+
+#include "FormatTestUtils.h"
+#include "clang/Format/Format.h"
+#include "llvm/Support/Debug.h"
+#include "gtest/gtest.h"
+
+#define DEBUG_TYPE "format-test"
+
+namespace clang {
+namespace format {
+
+class FormatTestJson : public ::testing::Test {
+protected:
+  static std::string format(llvm::StringRef Code, unsigned Offset,
+                            unsigned Length, const FormatStyle &Style) {
+    LLVM_DEBUG(llvm::errs() << "---\n");
+    LLVM_DEBUG(llvm::errs() << Code << "\n\n");
+    std::vector<tooling::Range> Ranges(1, tooling::Range(Offset, Length));
+    tooling::Replacements Replaces = reformat(Style, Code, Ranges);
+    auto Result = applyAllReplacements(Code, Replaces);
+    EXPECT_TRUE(static_cast<bool>(Result));
+    LLVM_DEBUG(llvm::errs() << "\n" << *Result << "\n\n");
+    return *Result;
+  }
+
+  static std::string
+  format(llvm::StringRef Code,
+         const FormatStyle &Style = getLLVMStyle(FormatStyle::LK_Json)) {
+    return format(Code, 0, Code.size(), Style);
+  }
+
+  static FormatStyle getStyleWithColumns(unsigned ColumnLimit) {
+    FormatStyle Style = getLLVMStyle(FormatStyle::LK_Json);
+    Style.ColumnLimit = ColumnLimit;
+    return Style;
+  }
+
+  static void
+  verifyFormat(llvm::StringRef Code,
+               const FormatStyle &Style = getLLVMStyle(FormatStyle::LK_Json)) {
+    EXPECT_EQ(Code.str(), format(Code, Style)) << "Expected code is not stable";
+    EXPECT_EQ(Code.str(), format(test::messUp(Code), Style));
+  }
+};
+
+TEST_F(FormatTestJson, JsonRecord) {
+  verifyFormat("{}");
+  verifyFormat("{\n"
+               "  \"name\": 1\n"
+               "}");
+  verifyFormat("{\n"
+               "  \"name\": \"Foo\"\n"
+               "}");
+}
+
+TEST_F(FormatTestJson, JsonArray) {
+  verifyFormat("[]");
+  verifyFormat("[\n"
+               "  1\n"
+               "]");
+  verifyFormat("[\n"
+               "  1,\n"
+               "  2\n"
+               "]");
+  verifyFormat("[\n"
+               "  {},\n"
+               "  {}\n"
+               "]");
+  verifyFormat("[\n"
+               "  {\n"
+               "    \"name\": 1\n"
+               "  },\n"
+               "  {}\n"
+               "]");
+}
+
+TEST_F(FormatTestJson, JsonIndent) {
+  FormatStyle Style = getLLVMStyle(FormatStyle::LK_Json);
+  Style.IndentWidth = 4;
+  verifyFormat("[]", Style);
+  verifyFormat("[\n"
+               "    1\n"
+               "]",
+               Style);
+  verifyFormat("[\n"
+               "    1,\n"
+               "    2\n"
+               "]",
+               Style);
+  verifyFormat("[\n"
+               "    {},\n"
+               "    {}\n"
+               "]",
+               Style);
+  verifyFormat("[\n"
+               "    {\n"
+               "        \"name\": 1\n"
+               "    },\n"
+               "    {}\n"
+               "]",
+               Style);
+
+  // BasicFormatting
+  Style.IndentWidth = 0;
+  verifyFormat("[]", Style);
+  verifyFormat("[1]", Style);
+  verifyFormat("[1,2]", Style);
+  verifyFormat("[{},{}]", Style);
+  verifyFormat("[{\"name\":1},{}]", Style);
+}
+
+} // namespace format
+} // end namespace clang