There are two options that do much the same thing, but for different
languages. With the addition to the doc, the user is less likely to
configure the wrong option and get frustrated that it doesn't work.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
It looks like your clang-format review does not contain any unit tests, please try to ensure all code changes have a unit test (unless this is an NFC or refactoring, adding documentation etc..)
Add you unit tests in clang/unittests/Format and build ninja FormatTests we recommend using the verifyFormat(xxx) format of unit tests rather than EXPECT_EQ as this will ensure you change is tolerant to random whitespace changes (see FormatTest.cpp as an example)
For situations where your change is altering the TokenAnnotator.cpp which can happen if you are trying to improve the annotation phase to ensure we are correctly identifying the type of a token, please add a token annotator test in TokenAnnotatorTest.cpp
Should we extend SpacesInContainerLiterals so that it controls JSON colons too? If yes, then we don't need SpaceBeforeJsonColon. Otherwise, IMO we should leave the doc alone.
My concern for SpacesInContainerLiterals is that it impacts arrays contents too '[ 1, 2, 3 ]'.
Thanks for testing this automated comment ;-) , I've fixed some of the grammatical issue and made it so it won't fire if NFC is in the title.
It looks like a line break gets inserted in arrays. Does that mean the option doesn't affect arrays?
It already affects JSON arrays if BreakArrays is set to false:
$ cat foo.json [1, 2, 3] $ clang-format -style='{BreakArrays: false}' foo.json [ 1, 2, 3 ]