|
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 |
|
| #
8bfccb96 |
| 21-May-2022 |
owenca <[email protected]> |
[clang-format] Fix an infinite loop in parseJavaEnumBody()
Fixes #55623.
|
|
Revision tags: 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 |
|
| #
7af11989 |
| 14-Jan-2022 |
Marek Kurdej <[email protected]> |
[clang-format] Fix short functions being considered as inline inside an indented namespace.
Fixes https://github.com/llvm/llvm-project/issues/24784.
With config: ``` AllowShortFunctionsOnASingleLin
[clang-format] Fix short functions being considered as inline inside an indented namespace.
Fixes https://github.com/llvm/llvm-project/issues/24784.
With config: ``` AllowShortFunctionsOnASingleLine: Inline NamespaceIndentation: All ```
The code: ``` namespace Test { void f() { return; } } ``` was incorrectly formatted to: ``` namespace Test { void f() { return; } } ```
since the function `f` was considered being inside a class/struct/record. That's because the check was simplistic and only checked for a non-zero indentation level of the line starting `f`.
Reviewed By: MyDeveloperDay, HazardyKnusperkeks
Differential Revision: https://reviews.llvm.org/D117142
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc2 |
|
| #
91b9e672 |
| 07-Jan-2022 |
Marek Kurdej <[email protected]> |
[clang-format] Fix `BraceWrapping: AfterFunction` affecting synchronized blocks in Java.
Fixes https://github.com/llvm/llvm-project/issues/32031.
Before this change, BraceWrapping: AfterFunction wo
[clang-format] Fix `BraceWrapping: AfterFunction` affecting synchronized blocks in Java.
Fixes https://github.com/llvm/llvm-project/issues/32031.
Before this change, BraceWrapping: AfterFunction would affect synchronized blocks in Java, but they should be formatted w.r.t. BraceWrapping: AfterControlStatement.
Using the config: ``` BreakBeforeBraces: Custom BraceWrapping: AfterControlStatement: false AfterFunction: true ```
would result in misformatted code like: ``` class Foo { void bar() { synchronized (this) { a(); a(); } } } ```
instead of: ``` class Foo { void bar() { synchronized (this) { a(); a(); } } } ```
Reviewed By: MyDeveloperDay, owenpan
Differential Revision: https://reviews.llvm.org/D116767
show more ...
|
|
Revision tags: 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 |
|
| #
ba3484c0 |
| 03-Jan-2020 |
Nico Weber <[email protected]> |
[clang-format/java] format multiple qualified annotations on one declaration better
Before: class Foo { @CommandLineFlags .Add @Features.foo public void test(
[clang-format/java] format multiple qualified annotations on one declaration better
Before: class Foo { @CommandLineFlags .Add @Features.foo public void test() {} }
Now: class Foo { @Features.foo @CommandLineFlags.Add public void test() { } }
See also https://crbug.com/1034115
show more ...
|
|
Revision tags: 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, 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 |
|
| #
749c1b59 |
| 19-Oct-2018 |
Hans Wennborg <[email protected]> |
Java annotation declaration being handled correctly
Previously, Java annotation declarations (@interface AnnotationName) were being handled as ObjC interfaces. This caused the brace formatting to me
Java annotation declaration being handled correctly
Previously, Java annotation declarations (@interface AnnotationName) were being handled as ObjC interfaces. This caused the brace formatting to mess up, so that when you had a class with an interface defined in it, it would indent the final brace of the class.
It used to format this class like so:
class A { @interface B {} }
But will now just skip the @interface and format it like so:
class A { @interface B {} }
Patch by Sam Maier!
Differential Revision: https://reviews.llvm.org/D53434
llvm-svn: 344789
show more ...
|
| #
208661b2 |
| 05-Oct-2018 |
Nico Weber <[email protected]> |
clang-format: Don't insert spaces in front of :: for Java 8 Method References.
The existing code kept the space if it was there for identifiers, and it didn't handle `this`. After this patch, for Ja
clang-format: Don't insert spaces in front of :: for Java 8 Method References.
The existing code kept the space if it was there for identifiers, and it didn't handle `this`. After this patch, for Java `this` is handled in addition to identifiers, and existing space is always stripped between identifier and `::`.
Also accept `::` in addition to `.` in front of `<` in `foo::<T>bar` generic calls.
Differential Revision: https://reviews.llvm.org/D52842
llvm-svn: 343872
show more ...
|
|
Revision tags: llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, 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 ...
|
|
Revision tags: llvmorg-6.0.1-rc1 |
|
| #
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, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2 |
|
| #
c29f83b7 |
| 23-Jan-2018 |
Nico Weber <[email protected]> |
clang-format: Support formatting Java 8 interface default methods.
llvm-svn: 323218
|
|
Revision tags: llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1 |
|
| #
b9b18675 |
| 27-Sep-2017 |
Nico Weber <[email protected]> |
clang-format/java: Unbreak genenrics formatting after r299952.
https://reviews.llvm.org/rL299952 merged '>>>' tokens into a single JavaRightLogicalShift token. This broke formatting of generics nest
clang-format/java: Unbreak genenrics formatting after r299952.
https://reviews.llvm.org/rL299952 merged '>>>' tokens into a single JavaRightLogicalShift token. This broke formatting of generics nested more than two deep, e.g. Foo<Bar<Baz>>> because the '>>>' now weren't three '>' for parseAngle().
Luckily, just deleting JavaRightLogicalShift fixes things without breaking the test added in r299952, so do that.
https://reviews.llvm.org/D38291
llvm-svn: 314325
show more ...
|
| #
e8eba371 |
| 25-Sep-2017 |
Nico Weber <[email protected]> |
clang-format/java: Always put space after `assert` keyword.
Previously, it was missing if the expression after the assert started with a (.
llvm-svn: 314172
|
|
Revision tags: llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1 |
|
| #
22d7e6b0 |
| 20-Jul-2017 |
Krasimir Georgiev <[email protected]> |
[clang-format] Put '/**' and '*/' on own lines in multiline jsdocs
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D35683
[clang-format] Put '/**' and '*/' on own lines in multiline jsdocs
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D35683
llvm-svn: 308684
show more ...
|
| #
d2130f51 |
| 30-Jun-2017 |
Francois Ferrand <[email protected]> |
clang-format: Do not binpack initialization lists
Summary: This patch tries to avoid binpacking when initializing lists/arrays, to allow things like:
static int types[] = { registerType1(),
clang-format: Do not binpack initialization lists
Summary: This patch tries to avoid binpacking when initializing lists/arrays, to allow things like:
static int types[] = { registerType1(), registerType2(), registerType3(), }; std::map<int, std::string> x = { { 0, "foo fjakfjaklf kljj" }, { 1, "bar fjakfjaklf kljj" }, { 2, "stuff fjakfjaklf kljj" }, };
This is similar to how dictionnaries are formatted, and actually corresponds to the same conditions: when initializing a container (and not just 'calling' a constructor).
Such formatting involves 2 things: * Line breaks around the content of the block. This can be forced by adding a comma or comment after the last element * Elements should not be binpacked
This patch considers the block is an initializer list if it either ends with a comma, or follows an assignment, which seems to provide a sensible approximation.
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: malcolm.parsons, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D34238
llvm-svn: 306868
show more ...
|
|
Revision tags: llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1 |
|
| #
48c94a61 |
| 11-Apr-2017 |
Nico Weber <[email protected]> |
[clang-format] Recognize Java logical shift assignment operator
At present, clang-format mangles Java containing logical right shift operators ('>>>=' or '>>>'), splitting them in two, resulting in
[clang-format] Recognize Java logical shift assignment operator
At present, clang-format mangles Java containing logical right shift operators ('>>>=' or '>>>'), splitting them in two, resulting in invalid code:
public class Minimal { public void func(String args) { int i = 42; - i >>>= 1; + i >> >= 1; return i; } }
This adds both forms of logical right shift to the FormatTokenLexer, so clang-format won't attempt to split them and insert bogus whitespace.
https://reviews.llvm.org/D31652 Patch from Richard Bradfield <[email protected]>!
llvm-svn: 299952
show more ...
|
|
Revision tags: llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3 |
|
| #
e154020d |
| 28-Feb-2017 |
Daniel Jasper <[email protected]> |
clang-format: [Java] Fix bug in enum formatting.
Before: public enum VeryLongEnum { ENUM_WITH_MANY_PARAMETERS("aaaaaaaaaaaaaaaaaaaaaa", "bbbbbbbbbbbbbbbbbbbbbbbbb
clang-format: [Java] Fix bug in enum formatting.
Before: public enum VeryLongEnum { ENUM_WITH_MANY_PARAMETERS("aaaaaaaaaaaaaaaaaaaaaa", "bbbbbbbbbbbbbbbbbbbbbbbbbbb", "ccccccccccccccccccc") , SECOND_ENUM("a", "b", "c");
private VeryLongEnum(String a, String b, String c) {} }
After: public enum VeryLongEnum { ENUM_WITH_MANY_PARAMETERS("aaaaaaaaaaaaaaaaaaaaaa", "bbbbbbbbbbbbbbbbbbbbbbbbbbb", "ccccccccccccccccccc") , SECOND_ENUM("a", "b", "c");
private VeryLongEnum(String a, String b, String c) {} }
llvm-svn: 296499
show more ...
|
|
Revision tags: llvmorg-4.0.0-rc2, llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1, llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1 |
|
| #
4f8d9943 |
| 11-Jul-2016 |
Eric Liu <[email protected]> |
Make tooling::applyAllReplacements return llvm::Expected<string> instead of empty string to indicate potential error.
Summary: return llvm::Expected<> to carry error status and error information. Th
Make tooling::applyAllReplacements return llvm::Expected<string> instead of empty string to indicate potential error.
Summary: return llvm::Expected<> to carry error status and error information. This is the first step towards introducing "Error" into tooling::Replacements.
Reviewers: djasper, klimek
Subscribers: ioeric, klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D21601
llvm-svn: 275062
show more ...
|
|
Revision tags: llvmorg-3.8.1, llvmorg-3.8.1-rc1, llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2 |
|
| #
15b01116 |
| 27-Jan-2016 |
Daniel Jasper <[email protected]> |
clang-format: [Java] Remove unnecessary line break after complex annotations
Before: @Annotation("Some" + " text") List<Integer> list;
After: @Annotation("Some" + " text")
clang-format: [Java] Remove unnecessary line break after complex annotations
Before: @Annotation("Some" + " text") List<Integer> list;
After: @Annotation("Some" + " text") List<Integer> list;
llvm-svn: 258981
show more ...
|
|
Revision tags: llvmorg-3.8.0-rc1 |
|
| #
72a1b6a5 |
| 22-Dec-2015 |
Daniel Jasper <[email protected]> |
clang-format: [JS] "operator" is not a keyword in Java/JavaScript.
llvm-svn: 256245
|
|
Revision tags: llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1 |
|
| #
2cd92f1c |
| 15-Oct-2015 |
Nico Weber <[email protected]> |
clang-format/java: Break after annotations on fields in Chromium style.
Chromium follows the Android style guide for Java code, and that doesn't make the distinction between fields and non-fields th
clang-format/java: Break after annotations on fields in Chromium style.
Chromium follows the Android style guide for Java code, and that doesn't make the distinction between fields and non-fields that the Google Java style guide makes:
https://source.android.com/source/code-style.html#use-standard-java-annotations https://google.github.io/styleguide/javaguide.html#s4.8.5-annotations
llvm-svn: 250422
show more ...
|
| #
8d8fc3f1 |
| 15-Sep-2015 |
Nico Weber <[email protected]> |
Remove accidental superfluous newline added in r247750.
llvm-svn: 247752
|
| #
4f113490 |
| 15-Sep-2015 |
Nico Weber <[email protected]> |
clang-format: In Java, `assert` is followed by an expression.
Before: assert a&& b; Now: assert a && b; llvm-svn: 247750
|
|
Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1 |
|
| #
043ac050 |
| 03-Jul-2015 |
Daniel Jasper <[email protected]> |
clang-format: [Java/JS] Properly support instanceof and its precedence.
llvm-svn: 241337
|
|
Revision tags: llvmorg-3.6.2, llvmorg-3.6.2-rc1 |
|
| #
ab9db510 |
| 22-Jun-2015 |
Alexander Kornienko <[email protected]> |
Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").
llvm-svn: 240353
|