Skip to content

Commit 7a14657

Browse files
committed
Documentation for the new ignore-next-node comments.
These docs explain how and where to apply the swift-format-ignore comment to disable formatting and source transformation rules.
1 parent 619f89b commit 7a14657

File tree

1 file changed

+83
-0
lines changed

1 file changed

+83
-0
lines changed

Documentation/IgnoringSource.md

Lines changed: 83 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,83 @@
1+
# `swift-format` Ignore/Disable Options
2+
3+
`swift-format` allows users to suppress formatting within a section of source
4+
code. At present, this is only supported on declarations and statements due to
5+
technical limitations of the formatter's implementation. When an ignore comment
6+
is present, the next ["node"](#understanding-nodes) in the source's AST
7+
representation is ignored by the formatter.
8+
9+
## Ignoring Formatting (aka indentation, line breaks, line length, etc.)
10+
11+
The formatter applies line length to add line breaks and indentation throughout
12+
source code. When this formatting isn't desired, it can be disabled by prefixing
13+
a declaration or statement with a comment that contains "swift-format-ignore".
14+
15+
```swift
16+
// swift-format-ignore
17+
struct Foo {
18+
var bar = true
19+
}
20+
21+
// swift-format-ignore
22+
func foo() {
23+
var bar = true
24+
}
25+
26+
// swift-format-ignore
27+
var a = foo+bar+baz
28+
```
29+
30+
Formatting is ignored for all children of the node where the ignore comment is
31+
placed. For example, an ignore comment before a function causes the formatter to
32+
ignore the entire code block of the function and an ignore comment before a
33+
struct or class causes the formatter to ignore all of its members.
34+
35+
## Ignoring Source Transforming Rules
36+
37+
In addition to line breaks and indentation, the formatter provides a number of
38+
rules that apply various source transformations to fix-up common issues in
39+
source code. These rules can be disabled with a similar comment for disabling
40+
formatting. All rules are disabled whenever a "swift-format-ignore" (with no
41+
rule names) comment is encountered. When you want to disable a specific rule or
42+
set of rules, add a comment of the form:
43+
44+
`// swift-format-ignore: [comma delimited list of rule names]`.
45+
46+
```swift
47+
// swift-format-ignore: BlankLineBetweenMembers
48+
struct Foo {
49+
var bar = true
50+
}
51+
52+
// swift-format-ignore: BlankLineBetweenMembers, FullyIndirectEnum, UseEarlyExits
53+
func foo() {
54+
var bar = true
55+
}
56+
57+
// swift-format-ignore
58+
var a = foo+bar+baz
59+
```
60+
61+
These ignore comments also apply to all children of the node, identical to the
62+
behavior of the formatting ignore directive described above.
63+
64+
## Understanding Nodes
65+
66+
`swift-format` parses Swift into an abstract syntax tree, where each element of
67+
the source is represented by a node. Formatting can only be suppressed on
68+
certain "top level nodes" due to limitations of the syntax visitor pattern used
69+
by the formatter. Limiting to these nodes ensures there will be no mismatched
70+
formatting instructions (i.e. start a group without a corresponding end). The
71+
top level nodes that support suppressing formatting are:
72+
73+
- `CodeBlockItemSyntax`, which is either:
74+
- A single expression (e.g. function call, assignment, expression)
75+
- A scoped block of code & associated statement(s) (e.g. function declaration,
76+
struct/class/enum declaration, if/guard statements, switch statement, while
77+
loop). All code nested syntactically inside of the ignored node is also
78+
ignored by the formatter. This means ignoring a struct declaration also
79+
ignores all code inside of the struct declaration.
80+
- `MemberDeclListItemSyntax`
81+
- Any member declaration inside of a declaration (e.g. properties and
82+
functions declared inside of a struct/class/enum). All code nested
83+
syntactically inside of the ignored node is also ignored by the formatter.

0 commit comments

Comments
 (0)