[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

15

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

278

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

15

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

278

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

- Option ``IfMacros`` has been added. This lets you define macros that get
   foreach loops.
 
 - ``git-clang-format`` no longer formats changes to symbolic links. (Fixes
   https://llvm.org/PR46992.)
 
 - Makes ``PointerAligment: Right`` working with ``AlignConsecutiveDeclarations``.
   (Fixes https://llvm.org/PR27353)
 
 - Option ``AlignArrayOfStructure`` has been added to allow for ordering array-like
   initializers.
 
+- Support for formatting JSON file (\*.json) has been added to clang-format.
+
 libclang
 --------
 
 - ...
 
 Static Analyzer
 ---------------
 

clang/include/clang/Format/Format.h

enum LanguageKind : unsigned char {
     /// 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;
 
   /// Indentation logic for lambda bodies.
   enum LambdaBodyIndentationKind : unsigned char {
     /// Align lambda body relative to the lambda signature. This is the default.
     /// \code
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/ContinuationIndenter.cpp

ContinuationIndenter::getRawStringStyle(const FormatToken &Current,
   return RawStringStyle;
 }
 
 std::unique_ptr<BreakableToken>
 ContinuationIndenter::createBreakableToken(const FormatToken &Current,
                                            LineState &State, bool AllowBreak) {
   unsigned StartColumn = State.Column - Current.ColumnWidth;
   if (Current.isStringLiteral()) {
-    // FIXME: String literal breaking is currently disabled for C#, Java and
-    // JavaScript, as it requires strings to be merged using "+" which we
+    // FIXME: String literal breaking is currently disabled for C#, Java, Json
+    // and JavaScript, as it requires strings to be merged using "+" which we
     // don't support.
     if (Style.Language == FormatStyle::LK_Java ||
         Style.Language == FormatStyle::LK_JavaScript || Style.isCSharp() ||
-        !Style.BreakStringLiterals || !AllowBreak)
+        Style.isJson() || !Style.BreakStringLiterals || !AllowBreak)
       return nullptr;
 
     // Don't break string literals inside preprocessor directives (except for
     // #define directives, as their contents are stored in separate lines and
     // are not affected by this check).
     // This way we avoid breaking code with line directives and unknown
     // preprocessor directives that contain long string literals.
     if (State.Line->Type == LT_PreprocessorDirective)

clang/lib/Format/Format.cpp

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
FormatStyle getLLVMStyle(FormatStyle::LanguageKind Language) {
   LLVMStyle.WhitespaceSensitiveMacros.push_back("BOOST_PP_STRINGIZE");
   LLVMStyle.WhitespaceSensitiveMacros.push_back("NS_SWIFT_NAME");
   LLVMStyle.WhitespaceSensitiveMacros.push_back("CF_SWIFT_NAME");
 
   // Defaults that differ when not C++.
   if (Language == FormatStyle::LK_TableGen) {
     LLVMStyle.SpacesInContainerLiterals = false;
   }
+  if (LLVMStyle.isJson()) {
+    LLVMStyle.ColumnLimit = 0;
+  }
 
   return LLVMStyle;
 }
 
 FormatStyle getGoogleStyle(FormatStyle::LanguageKind Language) {
   if (Language == FormatStyle::LK_TextProto) {
     FormatStyle GoogleStyle = getGoogleStyle(FormatStyle::LK_Proto);
     GoogleStyle.Language = FormatStyle::LK_TextProto;
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};
 
+  // JSON only needs the formatting passing.
+  if (Style.isJson()) {
+    std::vector<tooling::Range> Ranges(1, tooling::Range(0, Code.size()));
+    auto Env =
+        std::make_unique<Environment>(Code, FileName, Ranges, FirstStartColumn,
+                                      NextStartColumn, LastStartColumn);
+    // Perform the actual formatting pass.
+    tooling::Replacements Replaces =
+        Formatter(*Env, Style, Status).process().first;
+    // add a replacement to remove the "x = " from the result.
+    if (!Replaces.add(tooling::Replacement(FileName, 0, 4, ""))) {
+      // apply the reformatting changes and the removal of "x = ".
+      if (applyAllReplacements(Code, Replaces)) {
+        return {Replaces, 0};
+      }
+    }
+    return {tooling::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_insensitive(".textpb") ||
       FileName.endswith_insensitive(".pb.txt") ||
       FileName.endswith_insensitive(".textproto") ||
       FileName.endswith_insensitive(".asciipb"))
     return FormatStyle::LK_TextProto;
   if (FileName.endswith_insensitive(".td"))
     return FormatStyle::LK_TableGen;
   if (FileName.endswith_insensitive(".cs"))
     return FormatStyle::LK_CSharp;
+  if (FileName.endswith_insensitive(".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
if (!ChildFormatTextToApply.empty()) {
     assert(!Ec);
     static_cast<void>(Ec);
   }
 
   return FallbackStyle;
 }
 
 } // namespace format
-} // namespace clang
+} // namespace clang
 

clang/lib/Format/TokenAnnotator.cpp

return Style.SpaceBeforeParens == FormatStyle::SBPO_Always ||
           Right.ParameterCount > 0);
 }
 
 bool TokenAnnotator::spaceRequiredBetween(const AnnotatedLine &Line,
                                           const FormatToken &Left,
                                           const FormatToken &Right) {
   if (Left.is(tok::kw_return) && Right.isNot(tok::semi))
     return true;
+  if (Style.isJson() && Left.is(tok::string_literal) && Right.is(tok::colon))
+    return false;
   if (Left.is(Keywords.kw_assert) && Style.Language == FormatStyle::LK_Java)
     return true;
   if (Style.ObjCSpaceAfterProperty && Line.Type == LT_ObjCProperty &&
       Left.Tok.getObjCKeywordID() == tok::objc_property)
     return true;
   if (Right.is(tok::hashhash))
     return Left.is(tok::hash);
   if (Left.isOneOf(tok::hashhash, tok::hash))
if (Left.MatchingParen &&
       return !Style.Cpp11BracedListStyle;
     // A percent is probably part of a formatting specification, such as %lld.
     if (Left.is(tok::percent))
       return false;
     // Preserve the existence of a space before a percent for cases like 0x%04x
     // and "%d %d"
     if (Left.is(tok::numeric_constant) && Right.is(tok::percent))
       return HasExistingWhitespace();
+  } else if (Style.isJson()) {
+    if (Right.is(tok::colon))
+      return false;
   } else if (Style.isCSharp()) {
     // Require spaces around '{' and  before '}' unless they appear in
     // interpolated strings. Interpolated strings are merged into a single token
     // so cannot have spaces inserted by this function.
 
     // No space between 'this' and '['
     if (Left.is(tok::kw_this) && Right.is(tok::l_square))
       return false;
if (Right.is(tok::plus) && Left.is(tok::string_literal) && Right.Next &&
              Style.Language == FormatStyle::LK_ObjC ||
              Style.Language == FormatStyle::LK_Proto ||
              Style.Language == FormatStyle::LK_TableGen ||
              Style.Language == FormatStyle::LK_TextProto) {
     if (Left.isStringLiteral() && Right.isStringLiteral())
       return true;
   }
 
+  // Basic JSON newline processing.
+  if (Style.isJson()) {
+    // Always break after a JSON record opener.
+    // {
+    // }
+    if (Left.is(TT_DictLiteral) && Left.is(tok::l_brace))
+      return true;
+    // Always break after a JSON array opener.
+    // [
+    // ]
+    if (Left.is(TT_ArrayInitializerLSquare) && Left.is(tok::l_square) &&
+        !Right.is(tok::r_square))
+      return true;
+    // Always break afer successive entries.
+    // 1,
+    // 2
+    if (Left.is(tok::comma))
+      return true;
+  }
+
   // If the last token before a '}', ']', or ')' is a comma or a trailing
   // comment, the intention is to insert a line break after it in order to make
   // shuffling around entries easier. Import statements, especially in
   // JavaScript, can be an exception to this rule.
   if (Style.JavaScriptWrapImports || Line.Type != LT_ImportStatement) {
     const FormatToken *BeforeClosingBrace = nullptr;
     if ((Left.isOneOf(tok::l_brace, TT_ArrayInitializerLSquare) ||
          (Style.Language == FormatStyle::LK_JavaScript &&

clang/tools/clang-format/ClangFormat.cpp

if (SortIncludes.getNumOccurrences() != 0) {
     if (SortIncludes)
       FormatStyle->SortIncludes = FormatStyle::SI_CaseSensitive;
     else
       FormatStyle->SortIncludes = FormatStyle::SI_Never;
   }
   unsigned CursorPosition = Cursor;
   Replacements Replaces = sortIncludes(*FormatStyle, Code->getBuffer(), Ranges,
                                        AssumedFileName, &CursorPosition);
+
+  // To format JSON insert a variable to trick the code into thinking its
+  // JavaScript.
+  if (FormatStyle->isJson()) {
+    auto Err = Replaces.add(tooling::Replacement(
+        tooling::Replacement(AssumedFileName, 0, 0, "x = ")));
+    if (Err) {
+      llvm::errs() << "Bad Json variable insertion\n";
+    }
+  }
+
   auto ChangedCode = tooling::applyAllReplacements(Code->getBuffer(), Replaces);
   if (!ChangedCode) {
     llvm::errs() << llvm::toString(ChangedCode.takeError()) << "\n";
     return true;
   }
   // Get new affected ranges after sorting `#includes`.
   Ranges = tooling::calculateRangesAfterReplacements(Replaces, Ranges);
   FormattingAttemptStatus Status;

 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/tools/clang-format/clang-format-diff.py

parser.add_argument('-i', action='store_true', default=False,
                       help='apply edits to files instead of displaying a diff')
   parser.add_argument('-p', metavar='NUM', default=0,
                       help='strip the smallest prefix containing P slashes')
   parser.add_argument('-regex', metavar='PATTERN', default=None,
                       help='custom pattern selecting file paths to reformat '
                       '(case sensitive, overrides -iregex)')
   parser.add_argument('-iregex', metavar='PATTERN', default=
                       r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|hxx|m|mm|inc|js|ts'
-                      r'|proto|protodevel|java|cs)',
+                      r'|proto|protodevel|java|cs|json)',
                       help='custom pattern selecting file paths to reformat '
                       '(case insensitive, overridden by -regex)')
   parser.add_argument('-sort-includes', action='store_true', default=False,
                       help='let clang-format sort include blocks')
   parser.add_argument('-v', '--verbose', action='store_true',
                       help='be more verbose, ineffective without -i')
   parser.add_argument('-style',
                       help='formatting style to apply (LLVM, GNU, Google, Chromium, '

clang/tools/clang-format/git-clang-format

default_extensions = ','.join([
       'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx',  # C++
       'cu', 'cuh',  # CUDA
       # Other languages that clang-format supports
       'proto', 'protodevel',  # Protocol Buffers
       'java',  # Java
       'js',  # JavaScript
       'ts',  # TypeScript
       'cs',  # C Sharp
+      'json',  # Json
       ])
 
   p = argparse.ArgumentParser(
     usage=usage, formatter_class=argparse.RawDescriptionHelpFormatter,
     description=desc)
   p.add_argument('--binary',
                  default=config.get('clangformat.binary', 'clang-format'),
                  help='path to clang-format'),

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-json"
+
+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");
+
+    tooling::Replacements Replaces;
+
+    // Mock up what ClangFormat.cpp will do for JSON by adding a variable
+    // to trick JSON into being JavaScript
+    if (Style.isJson()) {
+      auto Err = Replaces.add(
+          tooling::Replacement(tooling::Replacement("", 0, 0, "x = ")));
+      if (Err) {
+        llvm::errs() << "Bad Json variable insertion\n";
+      }
+    }
+    auto ChangedCode = applyAllReplacements(Code, Replaces);
+    if (!ChangedCode) {
+      llvm::errs() << "Bad Json varibale replacement\n";
+    }
+    StringRef NewCode = *ChangedCode;
+
+    std::vector<tooling::Range> Ranges(1, tooling::Range(0, NewCode.size()));
+    Replaces = reformat(Style, NewCode, Ranges);
+    auto Result = applyAllReplacements(NewCode, 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"
+               "}");
+  verifyFormat("{\n"
+               "  \"name\": {\n"
+               "    \"value\": 1\n"
+               "  }\n"
+               "}");
+  verifyFormat("{\n"
+               "  \"name\": {\n"
+               "    \"value\": 1\n"
+               "  },\n"
+               "  \"name\": {\n"
+               "    \"value\": 2\n"
+               "  }\n"
+               "}");
+  verifyFormat("{\n"
+               "  \"name\": {\n"
+               "    \"value\": [\n"
+               "      1,\n"
+               "      2,\n"
+               "    ]\n"
+               "  }\n"
+               "}");
+  verifyFormat("{\n"
+               "  \"name\": {\n"
+               "    \"value\": [\n"
+               "      \"name\": {\n"
+               "        \"value\": 1\n"
+               "      },\n"
+               "      \"name\": {\n"
+               "        \"value\": 2\n"
+               "      }\n"
+               "    ]\n"
+               "  }\n"
+               "}");
+  verifyFormat(R"({
+  "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
+})");
+}
+
+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, JsonNoStringSplit) {
+  FormatStyle Style = getLLVMStyle(FormatStyle::LK_Json);
+  Style.IndentWidth = 4;
+  verifyFormat(
+      "[\n"
+      "    {\n"
+      "        "
+      "\"naaaaaaaa\": \"foooooooooooooooooooooo oooooooooooooooooooooo\"\n"
+      "    },\n"
+      "    {}\n"
+      "]",
+      Style);
+  verifyFormat("[\n"
+               "    {\n"
+               "        "
+               "\"naaaaaaaa\": "
+               "\"foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo"
+               "oooooooooooooooooooooooooo\"\n"
+               "    },\n"
+               "    {}\n"
+               "]",
+               Style);
+
+  Style.ColumnLimit = 80;
+  verifyFormat("[\n"
+               "    {\n"
+               "        "
+               "\"naaaaaaaa\":\n"
+               "            "
+               "\"foooooooooooooooooooooooooooooooooooooooooooooooooooooooooooo"
+               "oooooooooooooooooooooooooo\"\n"
+               "    },\n"
+               "    {}\n"
+               "]",
+               Style);
+}
+
+} // namespace format
+} // end namespace clang