This is a refactoring of:
- SpacesInConditionalStatement
- SpacesInCStyleCastParentheses
- SpaceInEmptyParentheses
- SpacesInParentheses
These are now options under the new Style Option: SpacesInParens. The
existing options are maintained for backward compatibility.
Within SpacesInParens, there are currently options for:
- Never
- Custom
The currently available options for Custom are:
- InConditionalStatements
- InCStyleCasts
- InEmptyParentheses
- Other
Setting InConditionalStatements and Other to true enables the same space
additions as SpacesInParentheses.
This refactoring does not add or remove any existing features, but it makes
it possible to more easily extend and maintain the addition of spaces within
parentheses.
Related to #55428.
Differential Revision: https://reviews.llvm.org/D155239
This adds a new AlignConsecutiveShortCaseStatements option in line with the
existing AlignConsecutive* options , which when
AllowShortCaseLabelsOnASingleLine is enabled will align the tokens after the
case statement's colon. This also adds a AlignCaseColons option to allow
aligning the case label colon itself rather than the token after it.
Fixes#55475.
Differential Revision: https://reviews.llvm.org/D151761
This adds a new AlignConsecutiveShortCaseStatements option in line with the
existing AlignConsecutive* options , which when
AllowShortCaseLabelsOnASingleLine is enabled will align the tokens after the
case statement's colon. This also adds a AlignCaseColons option to allow
aligning the case label colon itself rather than the token after it.
Fixes#55475.
Differential Revision: https://reviews.llvm.org/D151761
If a non-keyword identifier is found in TypeNames, then a *, &, or && that
follows it is annotated as TT_PointerOrReference.
Differential Revision: https://reviews.llvm.org/D155273
C89 and C99 list initializers are treated differently than Cpp11 braced
initializers. This patch identifies the C array/struct initializer lists by
finding the preceding equal sign before a left brace, and applies formatting
rules for BracketAlignmentStyle.BlockIndent to those list initializers.
Fixes#57878.
Differential Revision: https://reviews.llvm.org/D153205
After https://reviews.llvm.org/D151954 we've noticed some issues w/
clang-format behavior, as outlined in
https://github.com/llvm/llvm-project/issues/63170.
Valid C/C++ files, that were previously accepted, are now rejected by
clang-format, emitting the message:
"The new replacement overlaps with an existing replacement."
This reverts commit 4b9764959dc4b8783e18747c1742ab164e4bc4ee and
d2627cf88d2553a4c2e850430bdb908a4b7d2e52, which depends on it.
Reviewed By: phosek
Differential Revision: https://reviews.llvm.org/D152473
Adds an option KeepEmptyLinesAtEOF to keep empty lines (up to
MaxEmptyLinesToKeep) before EOF. This remedies the probably unintentional
change in behavior introduced in 3d3ea84a4f8f, which started to always
remove empty lines before EOF.
Fixes#56054.
Fixes#63150.
Differential Revision: https://reviews.llvm.org/D152305
Before:
```
module x
#( //
parameter x)
( //
input y);
endmodule
```
After:
```
module x
#(//
parameter x)
(//
input y);
endmodule
```
If the first line in a port or parameter list is not a comment, the
following lines will be aligned to the first line as intended:
```
module x
#(parameter x1,
parameter x2)
(input y,
input y2);
endmodule
```
Previously, the indentation would be changed to an extra continuation
indentation relative to the start of the parenthesis or the hash if
the first token inside the parentheses was a comment. It is a feature
introduced in ddaa9be97839. The feature enabled one to insert a `//`
comment right after an opening parentheses to put the function
arguments on a new line with a small indentation regardless of how
long the function name is, like this:
```
someFunction(anotherFunction( // Force break.
parameter));
```
People are unlikely to use this feature in a Verilog port list because
the formatter already puts the port list on its own lines. A comment
at the start of a port list is probably a comment for the port on the
next line.
We also removed the space before the comment so that its indentation
would be same as that for a line comment anywhere else in the port
list.
Reviewed By: HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D149562
The option allows users to specify how many columns to use to indent
the contents of initializer lists.
Closes#51070.
Differential Revision: https://reviews.llvm.org/D146101
This fix https://github.com/llvm/llvm-project/issues/61934
By default, the width property is used to set the width of a table column.
However, if the content of a cell in that column is wider than the width
specified by the width property, the cell's content will overflow the
column and the table will become wider than the specified width.
This causes the version numbers to be displayed outside of their table cells.
Using the min-width property instead of width ensures that the column is
wide enough to accommodate the content of its cells. If a cell's content is
wider than the specified min-width, the column will expand to fit the content.
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.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D147422
I've seen a couple of request for extra Json formatting to match prettier capability.
Reviewed By: owenpan
Differential Revision: https://reviews.llvm.org/D147003
Regenerate the style documentation, requires some minor sphinx changes to avoid warnings
Reviewed By: klimek
Differential Revision: https://reviews.llvm.org/D146704
This allows for the creation of permalinks to specific clang-format
options, for better sharing of a specific option and its options.
(I'm adding the usual clang-format reviewers on this patch because
I don't know any other reviewers that well, perhaps someone with
docs experience should be added instead...)
Note that I wanted to make minimal changes to make this happen and thus
landed on an unideal setup, but to me, it seems like the best out of
worse ones.
I could have made every style option a subheading, which would add
automatically the logic for permalinks and the little paragraph icon for
sharing.
However, this meant that the links themselves would be suboptimal, as
they'd include the whole text of the heading, including the type and
versionbadge, which is needless noise and could change, breaking the
concept of a "permalink". The format of the page could be changed to
put the option names on their own in a heading, and the other info below
it in a paragraph.
As Sphinx seems unwilling to fix https://github.com/sphinx-doc/sphinx/issues/1961,
there isn't a succinct way to change the "id" html field used for
sections
I could have used an add-on (https://github.com/GeeTransit/sphinx-better-subsection),
or made one myself, but I wanted to avoid extra dependencies for no
reason. (plus, I don't know how to make one myself.)
I could have used raw HTML for each heading, but that would immensely
pollute the rst file, which, while it is generated, is currently still
human-readable and it'd be nice for it to stay that way.
Also note that sphinx treats references as case-insensitive, which means
that they will all be lowercased in the resulting HTML. I envisioned
the ability to simply add #OptionName after the URL to get placed right
at the desired config option, which isn't possible without things such
as inline `raw` HTML.
To reconcile that, I added the ¶ paragraph buttons that can be used to
generate the link to the desired section, but since headings are not
actually used, they are faked and literally just a link following each
option, which means they stylistically don't match all other headings.
Also note that this sort-of assumes HTML output. I know Sphinx can
output other formats but I do not know if they are used. A non-html
output could embed unusable ¶ signs everywhere.
I'm okay with this patch being rejected in its current solution, or if
any of the above listed alternatives are better, they could be pursued
instead. In case the downsides of this solution are too much, I will
just create a feature request issue for this and maybe let someone more
experienced with Sphinx handle it, since this is still a feature I would
like to have. (and I do not want to deal with Sphinx at all after
battling with it for a whole day to produce a mediocre result.)
Reviewed By: HazardyKnusperkeks, owenpan, MyDeveloperDay, aaron.ballman
Differential Revision: https://reviews.llvm.org/D138446
This file is partially generated by a Python script in the
clang/docs/tools directory, but it's not obvious for people making
drive-by fixes. This comment hopefully helps people avoid making
changes that are later overwritten by the script.
It seems that changing Format.h is insufficient to get the docs to
rebuild? Changing the .rst file directly to at least see if that gets
the bot back to green finally.
This reverts commit 879bfe6a979295f834b76df66b19a203b93eed0f.
owenpan@ pointed out on https://reviews.llvm.org/D140956 that this
actually makes the formatting more consistent, so it's not a regression.
This reverts commit a28f0747c2f3728bd8a6f64f7c8ba80b4e0cda9f.
It appears that this regresses some function definitions, added an
example as a comment over at https://reviews.llvm.org/D140956.
Previously committed in 46c94e5067b5 which was reverted in f0756e086010
due to a memory bug.
Closes#58949.
Differential Revision: https://reviews.llvm.org/D140543
Revert "[clang-format] Disable FixRanges in IntegerLiteralSeparatorTest"
Breaks buildbots, details in https://reviews.llvm.org/D140543
This reverts commit 879bd9146a2c9ea395abd7c1ebd0f76f414a4967.
This reverts commit 46c94e5067b5f396c24bb950505c79bc819bd4b8.
CSS uses colons, not the equals sign. The final semicolon is optional,
but preferred to be included. Really, the font property doesn't really
need to be there, but I suppose it was put there for a reason.
It's surprising how lenient browsers are when parsing
Reviewed By: HazardyKnusperkeks, owenpan
Differential Revision: https://reviews.llvm.org/D138441
