forked from rosshemsley/SublimeClangFormat
-
Notifications
You must be signed in to change notification settings - Fork 0
/
clang_format_custom.sublime-settings
411 lines (341 loc) · 18.1 KB
/
clang_format_custom.sublime-settings
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
{
// All these settings have been taken from the clang-format manual,
// and can be customised form within Sublime Text settings files.
// Please note, the defaults set below are completely random values.
// Take a look at http://clang.llvm.org/docs/ClangFormatStyleOptions.html
// For examples.
// The style used for all options not specifically set in the configuration.
// Possible "values":
// LLVM
// Google
// Chromium
// Mozilla
// WebKit
"BasedOnStyle": "LLVM",
// The extra indent or outdent of access modifiers, e.g. "public":.
// "AccessModifierOffset": 2,
// If true, horizontally aligns arguments after an open bracket.
// This applies to round brackets (parentheses), angle brackets and square brackets.
// This will result in formattings like:
// Possible values:
// BAS_Align (in configuration: Align) Align parameters on the open bracket,
// e.g.:
// someLongFunction(argument1,
// argument2);
//
// BAS_DontAlign (in configuration: DontAlign) Don’t align, instead use
// ContinuationIndentWidth, e.g.:
// someLongFunction(argument1,
// argument2);
//
// BAS_AlwaysBreak (in configuration: AlwaysBreak) Always break after an
// open bracket, if the parameters don’t fit on a single line, e.g.:
// someLongFunction(
// argument1, argument2);
// "AlignAfterOpenBracket": true,
// If true, aligns consecutive assignments.
// This will align the assignment operators of consecutive lines.
// This will result in formattings like:
// int aaaa = 12;
// int b = 23;
// int ccc = 23;
// "AlignConsecutiveAssignments": true,
// If true, aligns consecutive declarations.
// This will align the declaration names of consecutive lines. This will result in formattings like
// int aaaa = 12;
// float b = 23;
// std::string ccc = 23;
// "AlignConsecutiveDeclarations": true,
// If true, aligns escaped newlines as far left as possible. Otherwise puts
// them into the right-most column.
// "AlignEscapedNewlinesLeft": true,
// If true, horizontally align operands of binary and ternary expressions.
// "AlignOperands": true,
// If true, aligns trailing comments.
// "AlignTrailingComments": true,
// Allow putting all parameters of a function declaration onto the next line
// even if BinPackParameters is false.
// "AllowAllParametersOfDeclarationOnNextLine": true,
// Allows contracting simple braced statements to a single line.
// E.g., this allows if (a) { return; } to be put on a single line.
// "AllowShortBlocksOnASingleLine": true,
// If true, short case labels will be contracted to a single line.
// "AllowShortCaseLabelsOnASingleLine": true,
// Dependent on the value, int f() { return 0; } can be put on a single
// line.
// Possible values:
// SFS_None (in "configuration": None) Never merge functions into a
// single line.
// SFS_Empty (in configuration: Empty) Only merge empty functions.
// SFS_Inline (in "configuration": Inline) Only merge functions defined
// inside a class.
// SFS_All (in "configuration": All) Merge all functions fitting on a
// single line.
// "AllowShortFunctionsOnASingleLine": "None",
// If true, if (a) return; can be put on a single line.
// "AllowShortIfStatementsOnASingleLine": false,
// If true, while (true) continue; can be put on a single line.
// "AllowShortLoopsOnASingleLine": true,
// The function definition return type breaking style to use.
// Possible values:
// DRTBS_None (in configuration: None) Break after return type automatically.
// PenaltyReturnTypeOnItsOwnLine is taken into account.
// DRTBS_All (in configuration: All) Always break after the return type.
// DRTBS_TopLevel (in configuration: TopLevel) Always break after the return types
// of top level functions.
// "AlwaysBreakAfterDefinitionReturnType": "None",
// "AlwaysBreakAfterReturnType": "None",
// If true, always break before multiline string literals.
// This flag is mean to make cases where there are multiple multiline
// strings in a file look more consistent. Thus, it will only take effect
// if wrapping the string at that point leads to it being indented
// ContinuationIndentWidth spaces from the start of the line.
// "AlwaysBreakBeforeMultilineStrings": true,
// If true, always break after the template<...> of a template declaration.
// "AlwaysBreakTemplateDeclarations": true,
// If false, a function call’s arguments will either be all on the same line
// or will have one line each.
// "BinPackArguments": true,
// If false, a function call’s or function definition’s parameters will
// either all be on the same line or will have one line each.
// "BinPackParameters": true,
// Control of individual brace wrapping cases.
// If BreakBeforeBraces is set to custom, use this to specify how each
// individual brace case should be handled. Otherwise, this is ignored.
// Nested configuration flags:
// bool AfterClass Wrap class definitions.
// bool AfterControlStatement Wrap control statements (if/for/while/switch/..).
// bool AfterEnum Wrap enum definitions.
// bool AfterFunction Wrap function definitions.
// bool AfterNamespace Wrap namespace definitions.
// bool AfterObjCDeclaration Wrap ObjC definitions (@autoreleasepool, interfaces, ..).
// bool AfterStruct Wrap struct definitions.
// bool AfterUnion Wrap union definitions.
// bool BeforeCatch Wrap before catch.
// bool BeforeElse Wrap before else.
// bool IndentBraces Indent the wrapped braces themselves.
// bool SplitEmptyFunction If false, empty function body can be put on a single line.
// bool SplitEmptyRecord If false, empty record (e.g. class, struct or union) body can be put on a single line.
// bool SplitEmptyNamespace If false, empty namespace body can be put on a single line.
"BraceWrapping":{
// "AfterClass": false,
// "AfterControlStatement": false,
// "AfterEnum": false,
// "AfterFunction": false,
// "AfterNamespace": false,
// "AfterObjCDeclaration": false,
// "AfterStruct": false,
// "AfterUnion": false,
// "BeforeCatch": false,
// "BeforeElse": false,
// "IndentBraces": false,
// "SplitEmptyFunction:" true,
// "SplitEmptyRecord": true,
// "SplitEmptyNamespace": true
},
// Break after each annotation on a field in Java files.
// "BreakAfterJavaFieldAnnotations": true,
// The way to wrap binary operators.
// Possible values:
// BOS_None (in configuration: None) Break after operators.
// BOS_NonAssignment (in configuration: NonAssignment) Break before operators that aren’t assignments.
// BOS_All (in configuration: All) Break before operators.
// "BreakBeforeBinaryOperators": "None",
// The brace breaking style to use.
// Possible "values":
// BS_Attach (in "configuration": Attach) Always attach braces to
// surrounding context.
// BS_Linux (in "configuration": Linux) Like Attach, but break before braces
// on function, namespace and class definitions.
// BS_Mozilla (in configuration: Mozilla) Like Attach, but break before
// braces on enum, function, and record definitions.
// BS_Stroustrup (in "configuration": Stroustrup) Like Attach, but break
// before function definitions.
// BS_Allman (in "configuration": Allman) Always break before braces.
// BS_GNU (in "configuration": GNU) Always break before braces and add an extra
// level of indentation to braces of control statements, not to those of
// class, function or other definitions.
// BS_WebKit (in configuration: WebKit) Like Attach, but break before functions.
// BS_Custom (in configuration: Custom) Configure each individual brace in
// BraceWrapping.
// "BreakBeforeBraces": "Attach",
// If true, ternary operators will be placed after line breaks.
// "BreakBeforeTernaryOperators": true,
// Always break constructor initializers before commas and align the commas
// with the colon.
// "BreakConstructorInitializersBeforeComma": true,
// The column limit. A column limit of 0 means that there is no column
// limit. In this case, clang-format will respect the input’s line breaking
// decisions within statements unless they contradict other rules.
// "ColumnLimit": 80,
// A regular expression that describes comments with special meaning, which
// should not be split into lines or otherwise changed.
// "CommentPragmas": "",
// If the constructor initializers don’t fit on a line, put each initializer
// on its own line.
// "ConstructorInitializerAllOnOneLineOrOnePerLine": true,
// The number of characters to use for indentation of constructor
// initializer lists.
// "ConstructorInitializerIndentWidth": 2,
// Indent width for line continuations.
// "ContinuationIndentWidth": 2,
// If true, format braced lists as best suited for C++11 braced lists.
// Important "differences": - No spaces inside the braced list. - No line
// break before the closing brace. - Indentation with the continuation
// indent, not with the block indent. Fundamentally, C++11 braced lists are
// formatted exactly like function calls would be formatted in their place.
// If the braced list follows a name (e.g. a type or variable name), clang-
// format formats as if the {} were the parentheses of a function call with
// that name. If there is no name, a zero-length name is assumed.
// "Cpp11BracedListStyle": true,
// If true, analyze the formatted file for the most common alignment of
// & and *. PointerAlignment is then used only as fallback.
// "DerivePointerAlignment": true,
// Disables formatting completely.
// "DisableFormat": false,
// If true, clang-format detects whether function calls and definitions are
// formatted with one parameter per line. Each call can be bin-packed, one-
// per-line or inconclusive. If it is inconclusive, e.g. completely on one
// line, but a decision needs to be made, clang-format analyzes whether
// there are other bin-packed cases in the input file and act accordingly.
// "NOTE": This is an experimental flag, that might go away or be renamed. Do
// not use this in config files, etc. Use at your own risk.
// "ExperimentalAutoDetectBinPacking": true,
// A vector of macros that should be interpreted as foreach loops instead of
// as function calls. These are expected to be macros of the "form":
// FOREACH(<variable-declaration>, ...)
// <loop-body>
// In the .clang-format configuration file, this can be configured like:
// ForEachMacros: ['RANGES_FOR', 'FOREACH']
// For example: BOOST_FOREACH.
// "ForEachMacros": "['RANGES_FOR', 'FOREACH']"
// Regular expressions denoting the different #include categories used for
// ordering #includes.
// These regular expressions are matched against the filename of an include
// (including the <> or “”) in order. The value belonging to the first
// matching regular expression is assigned and #includes are sorted first
// according to increasing category number and then alphabetically within
// each category.
// If none of the regular expressions match, UINT_MAX is assigned as
// category. The main header for a source file automatically gets
// category 0, so that it is kept at the beginning of the
// #includes (http://llvm.org/docs/CodingStandards.html#include-style).
// To configure this in the .clang-format file, use:
// IncludeCategories:
// - Regex: '^"(llvm|llvm-c|clang|clang-c)/'
// Priority: 2
// - Regex: '^(<|"(gtest|isl|json)/)'
// Priority: 3
// - Regex: '.\*'
// Priority: 1
// "IncludeCategories": "UINT_MAX"
// Indent case labels one level from the switch statement. When false, use
// the same indentation level as for the switch statement. Switch statement
// body is always indented one level more than case labels.
// "IndentCaseLabels": true,
// If true, indent when breaking function declarations which are not also
// definitions after the type.
// "IndentFunctionDeclarationAfterType": true,
// The number of columns to use for indentation.
// "IndentWidth": 2,
// Indent if a function definition or declaration is wrapped after the type.
// "IndentWrappedFunctionNames": true,
// If true, empty lines at the start of blocks are kept.
// "KeepEmptyLinesAtTheStartOfBlocks": true,
// Language, this format style is targeted at. Possible "values": LK_None
// (in "configuration": None) Do not use. LK_Cpp (in "configuration": Cpp)
// Should be used for C, C++, ObjectiveC, ObjectiveC++. LK_JavaScript (in
// "configuration": JavaScript) Should be used for JavaScript. LK_Proto (in
// "configuration": Proto) Should be used for Protocol Buffers
// ("https"://developers.google.com/protocol-buffers/).
// "Language": "Cpp",
// A regular expression matching macros that start a block.
// MacroBlockBegin: "*_MACRO_START"
// A regular expression matching macros that end a block.
// MacroBlockEnd: "*_MACRO_END",
// The maximum number of consecutive empty lines to keep.
// "MaxEmptyLinesToKeep": 2,
// The indentation used for namespaces.
// Possible "values":
// NI_None (in "configuration": None) Don’t indent in namespaces.
// NI_Inner (in "configuration": Inner) Indent only in inner namespaces
// (nested in other namespaces).
// NI_All (in "configuration": All) Indent in all namespaces.
// "NamespaceIndentation": "Inner",
// The number of characters to use for indentation of ObjC blocks.
// "ObjCBlockIndentWidth": 4,
// Add a space after @property in Objective-C, i.e. use @property (readonly)
// instead of @property(readonly).
// "ObjCSpaceAfterProperty": false,
// Add a space in front of an Objective-C protocol list, i.e. use Foo
// <Protocol> instead of Foo<Protocol>.
// "ObjCSpaceBeforeProtocolList": false,
// The penalty for breaking a function call after “call(”.
// "PenaltyBreakBeforeFirstCallParameter": 0,
// The penalty for each line break introduced inside a comment.
// "PenaltyBreakComment": 0,
// The penalty for breaking before the first <<.
// "PenaltyBreakFirstLessLess": 0,
// The penalty for each line break introduced inside a string literal.
// "PenaltyBreakString": 0,
// The penalty for each character outside of the column limit.
// "PenaltyExcessCharacter": 0,
// Penalty for putting the return type of a function onto its own line.
// "PenaltyReturnTypeOnItsOwnLine": 0,
// Pointer and reference alignment style.
// Possible values:
// PAS_Left (in configuration: Left) Align pointer to the left.
// PAS_Right (in configuration: Right) Align pointer to the right.
// PAS_Middle (in configuration: Middle) Align pointer in the middle.
// "PointerAlignment": "Left",
// If true, a space may be inserted after C style casts.
// "SpaceAfterCStyleCast": true,
// If false, spaces will be removed before assignment operators.
// "SpaceBeforeAssignmentOperators": true,
// Defines in which cases to put a space before opening parentheses.
// Possible "values":
// SBPO_Never (in "configuration": Never) Never put a space before opening
// parentheses.
// SBPO_ControlStatements (in "configuration": ControlStatements) Put a
// space before opening parentheses only after control statement keywords
// (for/if/while...).
// SBPO_Always (in "configuration": Always) Always put a space before
// opening parentheses, except when it’s prohibited by the syntax rules (in
// function- like macro definitions) or when determined by other style rules
// (after unary operators, opening parentheses, etc.)
// "SpaceBeforeParens": "ControlStatements",
// If true, spaces may be inserted into ‘()’.
// "SpaceInEmptyParentheses": true,
// The number of spaces before trailing line comments (//-comments). This
// does not affect trailing block comments (/**/-comments) as those commonly
// have different usage patterns and a number of special cases.
// "SpacesBeforeTrailingComments": 2,
// If true, spaces will be inserted after ‘<’ and before ‘>’ in template
// argument lists
// "SpacesInAngles": true,
// If true, spaces may be inserted into C style casts.
// "SpacesInCStyleCastParentheses": true,
// If true, spaces are inserted inside container literals (e.g. ObjC and
// Javascript array and dict literals).
// "SpacesInContainerLiterals": true,
// If true, spaces will be inserted after ‘(‘ and before ‘)’.
// "SpacesInParentheses": true,
// If true, spaces will be inserted after ‘[‘ and before ‘]’.
// "SpacesInSquareBrackets": true,
// Format compatible with this standard, e.g. use A<A<int> > instead of
// A<A<int>> for LS_Cpp03. Possible "values":
// LS_Cpp03 (in "configuration": Cpp03) Use C++03-compatible syntax.
// LS_Cpp11 (in "configuration": Cpp11) Use features of C++11 (e.g.
// A<A<int>> instead of A<A<int> >).
// LS_Auto (in "configuration": Auto) Automatic detection based on the input.
// "Standard": "Cpp03",
// The number of columns used for tab stops.
// "TabWidth": 2,
// The way to use tab characters in the resulting file.
// Possible "values":
// UT_Never (in "configuration": Never) Never use tab. UT_ForIndentation (in
// "configuration": ForIndentation) Use tabs only for indentation. UT_Always
// (in "configuration": Always) Use tabs whenever we need to fill whitespace
// that spans at least from one tab stop to the next one.
// "UseTab": "Never"
}