Summary:
There should be no line break before the opening brace for Microsoft style property accessors when the accessor is a simple `{ get; set }`.
https://docs.microsoft.com/en-us/dotnet/csharp/properties
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D81467
Summary:
{D80144} introduce an ObjC regression
Only parse the `[]` if what follows is really an attribute
Reviewers: krasimir, JakeMerdichAMD
Reviewed By: krasimir
Subscribers: rdwampler, aaron.ballman, curdeius, cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80547
Summary:
Its currently not possible to recreate the GNU style using the `BreakBeforeBraces: Custom` style due to a lack of missing `BeforeWhile` in the `BraceWrappingFlags`
The following request was raised to add `BeforeWhile` in a `do..while` context like `BeforeElse` and `BeforeCatch` to give greater control over the positioning of the `while`
https://bugs.llvm.org/show_bug.cgi?id=42164
Reviewers: krasimir, mitchell-stellar, sammccall
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79325
Summary:
https://bugs.llvm.org/show_bug.cgi?id=45614
`[[nodiscard]]` after a macro doesn't behave the same as an __attribute__ resulting in incorrect indentation
This revision corrects that behavior
See original Mozilla bug:
https://bugzilla.mozilla.org/show_bug.cgi?id=1629756
Before:
```
class FooWidget : public nsBaseWidget {
public:
FooWidget();
NS_DECL_ISUPPORTS_INHERITED
[[nodiscard]] nsresult
FunctionOne();
[[nodiscard]] nsresult FunctionTwo();
};
```
After:
```
class FooWidget : public nsBaseWidget {
public:
FooWidget();
NS_DECL_ISUPPORTS_INHERITED
[[nodiscard]] nsresult FunctionOne();
[[nodiscard]] nsresult FunctionTwo();
};
```
Reviewed By: Abpostelnicu
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79990
Summary:
https://bugs.llvm.org/show_bug.cgi?id=45942
With Chromium style (although that is not important) its just it defines PointerAligmment: Left
The following arguments `S&&` are formatted differently depending on if the class has an attribute between it and the class identifier
```
class S {
S(S&&) = default;
};
class [[nodiscard]] S {
S(S &&) = default;
};
```
The prescense of [[nodiscard]] between the `class/struct` and the `{` causes the `{` to be incorrectly seen as a `TT_FunctionLBrace` which in turn transforms all the && to be `TT_BinaryOperators` rather than `TT_PointerOrReference`, as binary operators other spacing rules come into play causing a miss format
This revision resolves this by allowing the parseRecord to consider the [[nodisscard]]
Reviewed By: Abpostelnicu
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D80008
Summary:
Allow brace wrapping in C# property accessors to be controlled by configuration options.
Add new tests and revert old test results for Microsoft style to their previous state (as intended).
`FormatStyle.BraceWrapping.AfterFunction = true;` will change automatic property formatting from
```
Type MyType { get; set }
```
to
```
Type MyType
{ get; set }
```
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir, MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D79000
Summary:
Currently the 'AlignConsecutive*' options incorrectly align across
elif and else statements, even if they are very far away and across
unrelated preprocessor macros.
This failed since on preprocessor run 2+, there is not enough context
about the #ifdefs to actually differentiate one block from another,
causing them to align across different blocks or even large sections of
the file.
Eg, with AlignConsecutiveAssignments:
```
\#if FOO // Run 1
\#else // Run 1
int a = 1; // Run 2, wrong
\#endif // Run 1
\#if FOO // Run 1
\#else // Run 1
int bar = 1; // Run 2
\#endif // Run 1
```
is read as
```
int a = 1; // Run 2, wrong
int bar = 1; // Run 2
```
The approach taken to fix this was to add a new flag to Token that
forces breaking alignment across groups of lines (MustBreakAlignBefore)
in a similar manner to the existing flag that forces a line break
(MustBreakBefore). This flag is set for the first Token after a
preprocessor statement or diff conflict marker.
Fixes #25167,#31281
Patch By: JakeMerdichAMD
Reviewed By: MyDeveloperDay
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79388
This enables us to intercept changes to the token type via setType(), which
is a precondition for being able to use multi-pass formatting for macro
arguments.
Differential Revision: https://reviews.llvm.org/D67405
Summary:
BTW my actual code that hit this issue is like
```
[a, b = std::move(b)](auto &&... c) mutable -> std::invoke_result_t<decltype(b), decltype(c)...> { /* omitted */ }
```
where this explicit return type is required for SFINAE.
Reviewed By: krasimir, MyDeveloperDay
Patch By: johnchen902
Subscribers: krasimir, dexonsmith, cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D78694
Summary:
Allow brace wrapping in C# property accessors to be controlled by configuration options.
Add new tests and revert old test results for MS style to their old state (as intended).
`FormatStyle.BraceWrapping.AfterFunction = true;` will change automatic property formatting from
```
Type MyType { get; set }
```
to
```
Type MyType
{ get; set }
```
Reviewers: krasimir, MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D79000
Summary:
Added some examples of properties from Microsoft documentation as test cases.
https://docs.microsoft.com/en-us/dotnet/csharp/programming-guide/classes-and-structs/properties
Configuration support will be added in a follow up patch to address whether automatic properties are formatted as
```
Type MyType { get; set }
```
or
```
Type MyType
{ get; set }
```
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D78915
Summary: In recent patches the clang-format code has become un-formatted, correct this before making additional changes
Reviewers: mitchell-stellar, sylvestre.ledru, Abpostelnicu, Wawha, jbcoe
Reviewed By: sylvestre.ledru, Abpostelnicu, jbcoe
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D78909
Summary:
Improve C# `{ get; set; } = default;` formatting by handling it in the UnwrappedLineParser rather than trying to merge lines later.
Remove old logic to merge lines.
Update tests as formatting output has changed (as intended).
Reviewers: krasimir, MyDeveloperDay
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D78642
Summary:
Treat each C# generic type constraint, `where T: ...`, as a line.
Add C# keyword: where
Add Token Types: CSharpGenericTypeConstraint, CSharpGenericTypeConstraintColon, CSharpGenericTypeConstraintComma.
This patch does not wrap generic type constraints well, that will be addressed in a follow up patch.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits, MyDeveloperDay
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D76367
Summary:
C# attributes can appear on classes and methods, in which case they should go on their own line, or on method parameters in which case
they should be left inline.
Reviewers: krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: klimek
Tags: #clang-format
Differential Revision: https://reviews.llvm.org/D74265
Summary:
The documentation for IndentCaseLabels claimed that the "Switch
statement body is always indented one level more than case labels". This
is technically false for the code block immediately following the label.
Its closing bracket aligns with the start of the label.
If the case label are not indented, it leads to a style where the
closing bracket of the block aligns with the closing bracket of the
switch statement, which can be hard to parse.
This change introduces a new option, IndentCaseBlocks, which when true
treats the block as a scope block (which it technically is).
(Note: regenerated ClangFormatStyleOptions.rst using tools/dump_style.py)
Reviewed By: MyDeveloperDay
Patch By: capn
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D72276
Summary:
Including `do`, `for`, and `while`, `if`, `else`, `try`, `catch`, in
addition to the previously handled fields. The unit test explicitly uses
methods, but this code path handles both fields and methods.
Reviewers: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D72827
Summary:
https://bugs.llvm.org/show_bug.cgi?id=44340
The rule that prevents `... {} [[....]]` being treated as a braced initializer for C++ causes problems for C# with attributes, causing it to be incorrectly classified and then messing up the subsequent formatting. (see bug for details of formatting)
Reviewers: mitchell-stellar, klimek, sammccall
Reviewed By: mitchell-stellar
Subscribers: cfe-commits
Tags: #clang-format, #clang
Differential Revision: https://reviews.llvm.org/D71769
The const-correctness of match() was fixed in rL372764, which allows
uses of Regex objects to be const in cases they couldn't be before. This
patch tightens up the const-ness of Regex in various such cases.
Reviewers: thopre
Reviewed By: thopre
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D68155
Summary:
Change the BraceWrappingFlags' AfterControlStatement from a bool to an enum with three values:
* "Never": This is the default, and does not do any brace wrapping after control statements.
* "MultiLine": This only wraps braces after multi-line control statements (this really only happens when a ColumnLimit is specified).
* "Always": This always wraps braces after control statements.
The first and last options are backwards-compatible with "false" and "true", respectively.
The new "MultiLine" option is useful for when a wrapped control statement's indentation matches the subsequent block's indentation. It makes it easier to see at a glance where the control statement ends and where the block's code begins. For example:
```
if (
foo
&& bar )
{
baz();
}
```
vs.
```
if (
foo
&& bar ) {
baz();
}
```
Short control statements (1 line) do not wrap the brace to the next line, e.g.
```
if (foo) {
bar();
} else {
baz();
}
```
Reviewers: sammccall, owenpan, reuk, MyDeveloperDay, klimek
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Patch By: mitchell-stellar
Tags: #clang-format, #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D68296
llvm-svn: 373647
This patch makes cases work where the lambda's template list doesn't
contain any of + - ! ~ / % << | || && ^ == != >= <= ? : true false
(see added FIXME).
Ports r359967 to clang-format.
Differential Revision: https://reviews.llvm.org/D67246
llvm-svn: 371854
Summary:
This option determines whether goto labels are indented according to scope. Setting this option to false causes goto labels to be flushed to the left.
This is mostly copied from [[ http://lists.llvm.org/pipermail/cfe-dev/2015-September/045014.html | this patch ]] submitted by Christian Neukirchen that didn't make its way into trunk.
```
true: false:
int f() { vs. int f() {
if (foo()) { if (foo()) {
label1: label1:
bar(); bar();
} }
label2: label2:
return 1; return 1;
} }
```
Reviewers: klimek, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: cfe-commits
Tags: #clang, #clang-tools-extra
Patch by: tetsuo-cpp
Differential Revision: https://reviews.llvm.org/D67037
llvm-svn: 371719
Now that we've moved to C++14, we no longer need the llvm::make_unique
implementation from STLExtras.h. This patch is a mechanical replacement
of (hopefully) all the llvm::make_unique instances across the monorepo.
Differential revision: https://reviews.llvm.org/D66259
llvm-svn: 368942
This is like r305666 (which added support for `if constexpr`) except
that it allows a macro name after the if.
This is slightly tricky for two reasons:
1. r305666 didn't add test coverage for all cases where it added a
kw_constexpr, so I had to figure out what all the added cases were
for. I now added tests for all `if constexpr` bits that didn't have
tests. (This took a while, see e.g. https://reviews.llvm.org/D65223)
2. Parsing `if <ident> (` as an if means that `#if defined(` and
`#if __has_include(` parse as ifs too. Add some special-case code
to prevent this from happening where it's incorrect.
Fixes PR39248.
Differential Revision: https://reviews.llvm.org/D65227
llvm-svn: 367167
Summary:
Other macros are used to declare namespaces, and should thus be handled
similarly. This is the case for crpcut's TESTSUITE macro, or for
unittest-cpp's SUITE macro:
TESTSUITE(Foo) {
TEST(MyFirstTest) {
assert(0);
}
} // TESTSUITE(Foo)
This patch deals with this cases by introducing a new option to specify
lists of namespace macros. Internally, it re-uses the system already in
place for foreach and statement macros, to ensure there is no impact on
performance.
Reviewers: krasimir, djasper, klimek
Reviewed By: klimek
Subscribers: acoomans, cfe-commits, klimek
Tags: #clang
Differential Revision: https://reviews.llvm.org/D37813
llvm-svn: 362740
Summary:
This option `AllowShortLambdasOnASingleLine` similar to the other `AllowShort*` options, but applied to C++ lambdas.
Reviewers: djasper, klimek
Reviewed By: klimek
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D57687
llvm-svn: 357027
Summary:
This revision adds basic support for formatting C# files with clang-format, I know the barrier to entry is high here so I'm sending this revision in to test the water as to whether this might be something we'd consider landing.
Tracking in Bugzilla as:
https://bugs.llvm.org/show_bug.cgi?id=40850
Justification:
C# code just looks ugly in comparison to the C++ code in our source tree which is clang-formatted.
I've struggled with Visual Studio reformatting to get a clean and consistent style, I want to format our C# code on saving like I do now for C++ and i want it to have the same style as defined in our .clang-format file, so it consistent as it can be with C++. (Braces/Breaking/Spaces/Indent etc..)
Using clang format without this patch leaves the code in a bad state, sometimes when the BreakStringLiterals is set, it fails to compile.
Mostly the C# is similar to Java, except instead of JavaAnnotations I try to reuse the TT_AttributeSquare.
Almost the most valuable portion is to have a new Language in order to partition the configuration for C# within a common .clang-format file, with the auto detection on the .cs extension. But there are other C# specific styles that could be added later if this is accepted. in particular how `{ set;get }` is formatted.
Reviewers: djasper, klimek, krasimir, benhamilton, JonasToth
Reviewed By: klimek
Subscribers: llvm-commits, mgorny, jdoerfert, cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D58404
llvm-svn: 356662
mydeveloperday