|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1 |
|
| #
ece7e95f |
| 02-May-2020 |
mydeveloperday <[email protected]> |
[clang-format] NFC - clang-format the FormatTests
Summary:
Ensure the clang-format unit tests are themselves clang-formatted
Having areas of the llvm code which are clang-format clean, give us more
[clang-format] NFC - clang-format the FormatTests
Summary:
Ensure the clang-format unit tests are themselves clang-formatted
Having areas of the llvm code which are clang-format clean, give us more areas to run new clang-format binaries on ensuring we haven't broken anything.
It seems to me we SHOULD have this clang-formatted at a minimum, otherwise how can we expect others to use clang-format if we "don't eat our own dogfood", also if the tests are dependent on the formatting of the code then that would also be bad!
Reviewed By: sammccall
Subscribers: cfe-commits
Tags: #clang, #clang-format
Differential Revision: https://reviews.llvm.org/D79204
show more ...
|
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3, llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
| #
4dea1378 |
| 10-May-2019 |
Krasimir Georgiev <[email protected]> |
Revert "Revert "[clang-format] Keep protobuf "package" statement on one line""
Summary:
Top-level "package" and "import" statements should generally be kept on
one line, for all languages.
----
Th
Revert "Revert "[clang-format] Keep protobuf "package" statement on one line""
Summary:
Top-level "package" and "import" statements should generally be kept on
one line, for all languages.
----
This reverts commit rL356912.
The regression from rL356835 was fixed via rC358275.
Reviewers: krasimir, sammccall, MyDeveloperDay, xinz, dchai, klimek
Reviewed By: krasimir, xinz, dchai
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60661
llvm-svn: 360411
show more ...
|
| #
69150467 |
| 12-Apr-2019 |
Krasimir Georgiev <[email protected]> |
[clang-format] Use SpacesBeforeTrailingComments for "option" directive
Summary:
AnnotatingParser::next() is needed to implicitly set TT_BlockComment
versus TT_LineComment. On most other paths throu
[clang-format] Use SpacesBeforeTrailingComments for "option" directive
Summary:
AnnotatingParser::next() is needed to implicitly set TT_BlockComment
versus TT_LineComment. On most other paths through
AnnotatingParser::parseLine(), all tokens are consumed to achieve that.
This change updates one place where this wasn't done.
Contributed by @dchai!
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60541
llvm-svn: 358275
show more ...
|
| #
ae3fefe3 |
| 25-Mar-2019 |
Haojian Wu <[email protected]> |
Revert "[clang-format] Keep protobuf "package" statement on one line"
This reverts commit r356835. This patch causes a regression, see the
test below:
verifyFormat("// Detached comment\n\n"
Revert "[clang-format] Keep protobuf "package" statement on one line"
This reverts commit r356835. This patch causes a regression, see the
test below:
verifyFormat("// Detached comment\n\n"
"// Leading comment\n"
"syntax = \"proto2\"; // trailing comment\n\n"
"// in foo.bar package\n"
"package foo.bar; // foo.bar package\n");
llvm-svn: 356912
show more ...
|
| #
f5e52738 |
| 23-Mar-2019 |
Paul Hoad <[email protected]> |
[clang-format] Keep protobuf "package" statement on one line
Summary:
Top-level "package" and "import" statements should generally be kept on one
line, for all languages.
Reviewers: sammccall, kras
[clang-format] Keep protobuf "package" statement on one line
Summary:
Top-level "package" and "import" statements should generally be kept on one
line, for all languages.
Reviewers: sammccall, krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59627
Patch By: dchai (Donald Chai)
llvm-svn: 356835
show more ...
|
| #
a87ba1c5 |
| 23-Mar-2019 |
Paul Hoad <[email protected]> |
[clang-format] correctly format protobuf fields named "enum".
Summary: Similar to TypeScript, "enum" is not a reserved word.
Reviewers: krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscr
[clang-format] correctly format protobuf fields named "enum".
Summary: Similar to TypeScript, "enum" is not a reserved word.
Reviewers: krasimir, MyDeveloperDay
Reviewed By: MyDeveloperDay
Subscribers: MyDeveloperDay, cfe-commits
Tags: #clang, #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D59629
Patch by: dchai (Donald Chai)
llvm-svn: 356833
show more ...
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2 |
|
| #
67e6521a |
| 15-Aug-2018 |
Daniel Jasper <[email protected]> |
clang-format: Change Google style wrt. the formatting of empty messages.
Before:
message Empty {
}
After:
message Empty {}
llvm-svn: 339803
|
|
Revision tags: llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3 |
|
| #
70a9e47f |
| 12-Jun-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] Discourage breaks in submessage entries, hard rule
Summary:
Currently clang-format allows this for text protos:
```
submessage:
{ key: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' }
`
[clang-format] Discourage breaks in submessage entries, hard rule
Summary:
Currently clang-format allows this for text protos:
```
submessage:
{ key: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa' }
```
when it is under the column limit and when putting it all on one line exceeds the column limit.
This is not a very intuitive formatting, so I'd prefer having
```
submessage: {
key: 'aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa'
}
```
instead, even if it takes one line more.
This patch prevents clang-format from inserting a break between `: {` and similar cases.
Reviewers: djasper, sammccall
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D48063
llvm-svn: 334517
show more ...
|
| #
8b98f551 |
| 11-Jun-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] text protos: put entries on separate lines if there is a submessage
Summary:
This patch updates clang-format text protos to put entries of a submessage into separate lines if the subm
[clang-format] text protos: put entries on separate lines if there is a submessage
Summary:
This patch updates clang-format text protos to put entries of a submessage into separate lines if the submessage contains at least two entries and contains at least one submessage entry.
For example, the entries here are kept on separate lines even if putting them on a single line would be under the column limit:
```
message: {
entry: 1
submessage: { key: value }
}
```
Messages containing a single submessage or several scalar entries can still be put on one line if they fit:
```
message { submessage { key: value } }
message { x: 1 y: 2 z: 3 }
```
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D46757
llvm-svn: 334401
show more ...
|
|
Revision tags: llvmorg-6.0.1-rc2 |
|
| #
3538b39e |
| 15-May-2018 |
Nicola Zaghen <[email protected]> |
[clang] Update uses of DEBUG macro to LLVM_DEBUG.
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\
[clang] Update uses of DEBUG macro to LLVM_DEBUG.
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
Explicitly avoided changing the strings in the clang-format tests.
Differential Revision: https://reviews.llvm.org/D44975
llvm-svn: 332350
show more ...
|
| #
8b4bc76a |
| 09-May-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] Respect BreakBeforeClosingBrace while calculating length
Summary:
This patch makes `getLengthToMatchingParen` respect the `BreakBeforeClosingBrace`
ParenState for matching scope close
[clang-format] Respect BreakBeforeClosingBrace while calculating length
Summary:
This patch makes `getLengthToMatchingParen` respect the `BreakBeforeClosingBrace`
ParenState for matching scope closers. In order to distinguish between paren states
introduced by real vs. fake parens, I've added the token opening the ParensState
to that struct.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D46519
llvm-svn: 331857
show more ...
|
| #
d6824876 |
| 23-Apr-2018 |
Krasimir Georgiev <[email protected]> |
Revert "[clang-format] Improve Incomplete detection for (text) protos"
This reverts commit r330016.
The incomplete detection has too many false positives, picking up typos
for hard failures and refu
Revert "[clang-format] Improve Incomplete detection for (text) protos"
This reverts commit r330016.
The incomplete detection has too many false positives, picking up typos
for hard failures and refusing to format anything in that case.
llvm-svn: 330569
show more ...
|
|
Revision tags: llvmorg-6.0.1-rc1 |
|
| #
f28347ea |
| 13-Apr-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] Improve Incomplete detection for (text) protos
Summary:
This patch improves detection of incomplete code for protos and text protos.
This is especially important for text protos in ra
[clang-format] Improve Incomplete detection for (text) protos
Summary:
This patch improves detection of incomplete code for protos and text protos.
This is especially important for text protos in raw string literals, since they
might be partial strings concatenated, and we'd like to disable formatting in
these cases.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D44203
llvm-svn: 330016
show more ...
|
| #
44e2e9f1 |
| 05-Apr-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] Preserve spaces before a percent in (text) protos
This makes sure that we do not change the meaning of pieces of text with
format specifiers.
llvm-svn: 329263
|
| #
c9a918c5 |
| 04-Apr-2018 |
Mark Zeren <[email protected]> |
[clang-format] In tests, expected code should be format-stable
Summary: Extend various verifyFormat helper functions to check that the
expected text is "stable". This provides some protection agains
[clang-format] In tests, expected code should be format-stable
Summary: Extend various verifyFormat helper functions to check that the
expected text is "stable". This provides some protection against bugs
where formatting results are ocilating between two forms, or continually
change in some other way.
Testing Done:
* Ran unit tests.
* Reproduced a known instability in preprocessor indentation which was
caught by this new check.
Reviewers: krasimir
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42034
llvm-svn: 329231
show more ...
|
|
Revision tags: llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1 |
|
| #
9c95dfe6 |
| 12-Mar-2018 |
Daniel Jasper <[email protected]> |
clang-format: Properly handle implicit string concatenation in text protos
Three issues to fix:
- char_constants weren't properly treated as string literals
- Prevening the break after "label: " doe
clang-format: Properly handle implicit string concatenation in text protos
Three issues to fix:
- char_constants weren't properly treated as string literals
- Prevening the break after "label: " does not make sense in concunction
with AlwaysBreakBeforeMultilineStrings. It leads to situations where
clang-format just cannot find a viable format (it must break and yet
it must not break).
- AlwaysBreakBeforeMultilineStrings should not be on for LK_TextProto in
Google style.
llvm-svn: 327255
show more ...
|
|
Revision tags: llvmorg-6.0.0 |
|
| #
0aa4b4cb |
| 27-Feb-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] Format operator key in protos
Summary: This fixes a glitch where ``operator: value`` in a text proto would mess up the underlying formatting since it gets parsed as a kw_operator inst
[clang-format] Format operator key in protos
Summary: This fixes a glitch where ``operator: value`` in a text proto would mess up the underlying formatting since it gets parsed as a kw_operator instead of an identifier.
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43830
llvm-svn: 326227
show more ...
|
|
Revision tags: llvmorg-6.0.0-rc3 |
|
| #
9b2aa42f |
| 19-Feb-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] Fixup a case of text proto message attributes
Summary: This patch fixes a case where a proto message attribute is wrongly identified as an text proto extension.
Subscribers: klimek,
[clang-format] Fixup a case of text proto message attributes
Summary: This patch fixes a case where a proto message attribute is wrongly identified as an text proto extension.
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43465
llvm-svn: 325509
show more ...
|
| #
b79987a9 |
| 15-Feb-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] Support repeated field lists in protos
Summary:
This patch adds support for list initialization of proto repeated fields:
```
keys: [1, 2, 3]
```
Reviewers: djasper
Reviewed By: dja
[clang-format] Support repeated field lists in protos
Summary:
This patch adds support for list initialization of proto repeated fields:
```
keys: [1, 2, 3]
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43298
llvm-svn: 325252
show more ...
|
| #
76064a4b |
| 14-Feb-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] Recognize percents as format specifiers in protos
Summary:
Frequently, a percent in protos denotes a formatting specifier for string replacement.
Thus it is desirable to keep the perc
[clang-format] Recognize percents as format specifiers in protos
Summary:
Frequently, a percent in protos denotes a formatting specifier for string replacement.
Thus it is desirable to keep the percent together with what follows after it.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43294
llvm-svn: 325159
show more ...
|
| #
4e290648 |
| 13-Feb-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] Support text proto extensions
Summary:
This adds support for text proto extensions, like:
```
msg {
[type.type/ext] {
key: value
}
}
```
Reviewers: djasper
Reviewed By: djas
[clang-format] Support text proto extensions
Summary:
This adds support for text proto extensions, like:
```
msg {
[type.type/ext] {
key: value
}
}
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D43180
llvm-svn: 324995
show more ...
|
| #
374e6de8 |
| 08-Feb-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] Do not break before long string literals in protos
Summary:
This patch is a follow-up to r323319 (which disables string literal breaking for
text protos) and it disables breaking befo
[clang-format] Do not break before long string literals in protos
Summary:
This patch is a follow-up to r323319 (which disables string literal breaking for
text protos) and it disables breaking before long string literals.
For example this:
```
keyyyyy: "long string literal"
```
used to get broken into:
```
keyyyyy:
"long string literal"
```
While at it, I also enabled it for LK_Proto and fixed a bug in the mustBreak code.
Reviewers: djasper, sammccall
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42957
llvm-svn: 324591
show more ...
|
|
Revision tags: llvmorg-6.0.0-rc2 |
|
| #
a79d62d2 |
| 06-Feb-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] Adds space around angle brackets in text protos
Summary:
This patch adds spaces around angle brackets in text proto Google style.
Previously these were detected as template openers an
[clang-format] Adds space around angle brackets in text protos
Summary:
This patch adds spaces around angle brackets in text proto Google style.
Previously these were detected as template openers and closers, which happened
to have the expected effect. Now we detect them as scope openers and closers
similarly to the way braces are handled in this context.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42727
llvm-svn: 324337
show more ...
|
| #
c2091808 |
| 31-Jan-2018 |
Krasimir Georgiev <[email protected]> |
[clang-format] Adds space around braces in text protos
Summary:
This patch modifies the text proto Google style to add spaces around braces.
I investigated using something different than Cpp11Brace
[clang-format] Adds space around braces in text protos
Summary:
This patch modifies the text proto Google style to add spaces around braces.
I investigated using something different than Cpp11BracedListStyle, but it turns out it's what we want and also the java and js styles also depend on that.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D42685
llvm-svn: 323860
show more ...
|