| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Consistently use `constexpr StringRef Code("string literal");`.
|
|
Fix #61954
|
|
There is some code to make sure that C++ keywords that are identifiers
in the other languages are not treated as keywords. Right now, the kind
is set to identifier, and the identifier info is cleared. The latter is
probably so that the code for identifying C++ structures does not
recognize those structures by mistake when formatting a language that
does not have those structures. But we did not find an instance where
the language can have the sequence of tokens, the code tries to parse
the structure as if it is C++ using the identifier info instead of the
token kind, but without checking for the language setting. However,
there are places where the code checks whether the identifier info field
is null or not. They are places where an identifier and a keyword are
treated the same way. For example, the name of a function in
JavaScript. This patch removes the lines that clear the identifier
info. This way, a C++ keyword gets treated in the same way as an
identifier in those places.
JavaScript
New
```JavaScript
async function
union(
myparamnameiswaytooloooong) {
}
```
Old
```JavaScript
async function
union(
myparamnameiswaytooloooong) {
}
```
Java
New
```Java
enum union { ABC, CDE }
```
Old
```Java
enum
union { ABC, CDE }
```
This reverts commit 97dcbdef6089175c45e14fcbcf5c88b10233a79a.
|
|
This reverts commit ab7cee8a0ecf29fdb47c64c8d431a694d63390d2 which had
formatting errors.
|
|
There is some code to make sure that C++ keywords that are identifiers
in the other languages are not treated as keywords. Right now, the kind
is set to identifier, and the identifier info is cleared. The latter is
probably so that the code for identifying C++ structures does not
recognize those structures by mistake when formatting a language that
does not have those structures. But we did not find an instance where
the language can have the sequence of tokens, the code tries to parse
the structure as if it is C++ using the identifier info instead of the
token kind, but without checking for the language setting. However,
there are places where the code checks whether the identifier info field
is null or not. They are places where an identifier and a keyword are
treated the same way. For example, the name of a function in
JavaScript. This patch removes the lines that clear the identifier
info. This way, a C++ keyword gets treated in the same way as an
identifier in those places.
JavaScript
New
```JavaScript
async function
union(
myparamnameiswaytooloooong) {
}
```
Old
```JavaScript
async function
union(
myparamnameiswaytooloooong) {
}
```
Java
New
```Java
enum union { ABC, CDE }
```
Old
```Java
enum
union { ABC, CDE }
```
|
|
Also adds AllowShortCaseExpressionOnASingleLine option and
AlignCaseArrows suboption of AlignConsecutiveShortCaseStatements.
Fixes #55903.
|
|
spaces in [] needs to be handled the same in Java the same as C#.
Co-authored-by: paul_hoad <paul_hoad@amat.com>
|
|
|
|
Now strings that are too long for one line in C#, Java, JavaScript, and
Verilog get broken into several lines. C# and JavaScript interpolated
strings are not broken.
A new subclass BreakableStringLiteralUsingOperators is used to handle
the logic for adding plus signs and commas. The updateAfterBroken
method was added because now parentheses or braces may be required after
the parentheses or commas are added. In order to decide whether the
added plus sign should be unindented in the BreakableToken object, the
logic for it is taken out into a separate function
shouldUnindentNextOperator.
The logic for finding the continuation indentation when the option
AlignAfterOpenBracket is set to DontAlign is not implemented yet. So in
that case the new line may have the wrong indentation, and the parts may
have the wrong length if the string needs to be broken more than once
because finding where to break the string depends on where the string
starts.
The preambles for the C# and Java unit tests are changed to the newer
style in order to allow the 3-argument verifyFormat macro. Some cases
are changed from verifyFormat to verifyImcompleteFormat because those
use incomplete code and the new verifyFormat function checks that the
code is complete.
The line in the doc was changed to being indented by 4 spaces, that is,
the default continuation indentation. It has always been the case. It
was probably a mistake that the doc showed 2 spaces previously.
This commit was fist committed as 16ccba51072b. The tests caused
assertion failures. Then it was reverted in 547bce36132a.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D154093
|
|
This reverts commit 16ccba51072bbc5ff4c66f91f939163dc91e5d96.
This is failing across Linaro's bots e.g.:
https://lab.llvm.org/buildbot/#/builders/188/builds/34393
|
|
Now strings that are too long for one line in C#, Java, JavaScript, and
Verilog get broken into several lines. C# and JavaScript interpolated
strings are not broken.
A new subclass BreakableStringLiteralUsingOperators is used to handle
the logic for adding plus signs and commas. The updateAfterBroken
method was added because now parentheses or braces may be required after
the parentheses or commas are added. In order to decide whether the
added plus sign should be unindented in the BreakableToken object, the
logic for it is taken out into a separate function
shouldUnindentNextOperator.
The logic for finding the continuation indentation when the option
AlignAfterOpenBracket is set to DontAlign is not implemented yet. So in
that case the new line may have the wrong indentation, and the parts may
have the wrong length if the string needs to be broken more than once
because finding where to break the string depends on where the string
starts.
The preambles for the C# and Java unit tests are changed to the newer
style in order to allow the 3-argument verifyFormat macro. Some cases
are changed from verifyFormat to verifyImcompleteFormat because those
use incomplete code and the new verifyFormat function checks that the
code is complete.
The line in the doc was changed to being indented by 4 spaces, that is,
the default continuation indentation. It has always been the case. It
was probably a mistake that the doc showed 2 spaces previously.
Reviewed By: MyDeveloperDay
Differential Revision: https://reviews.llvm.org/D154093
|
|
This patch adds a verifyNoChange macro to verify code that won't
change after being formatted. (The code will not be messed up before
being formatted.) It then replaces EXPECT_EQ with verifyFormat
wherever applicable so that the code will be messed up before being
formatted. When the replacement fails the unit test, verifyFormat is
replaced with verifyNoChange.
Differential Revision: https://reviews.llvm.org/D153109
|
|
- Modify TokenAnnotator to work fine with java-style array declarations.
- Add test for aligning of java declarations.
Fixes #55931.
Differential Revision: https://reviews.llvm.org/D129628
|
|
Fixes #55623.
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
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
|
|
llvm-svn: 323218
|
|
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
|
|
Previously, it was missing if the expression after the assert started with a (.
llvm-svn: 314172
|
|
Reviewers: mprobst
Reviewed By: mprobst
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D35683
llvm-svn: 308684
|
|
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
|
|
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 <bradfier@fstab.me>!
llvm-svn: 299952
|
|
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
|
|
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
|
|
Before:
@Annotation("Some"
+ " text")
List<Integer>
list;
After:
@Annotation("Some"
+ " text")
List<Integer> list;
llvm-svn: 258981
|
|
llvm-svn: 256245
|
|
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
|
|
llvm-svn: 247752
|
|
Before: assert a&& b;
Now: assert a && b;
llvm-svn: 247750
|
|
llvm-svn: 241337
|
|
llvm-svn: 240353
|
|
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
|
llvm-svn: 239903
|
|
Before:
aaaaaaaaaaa //
.aaaa( //
bbbb) // This is different ..
.aaaa( //
cccc); // .. from this.
After:
aaaaaaaaaaa //
.aaaa( //
bbbb) // This is identical ..
.aaaa( //
cccc); // .. to this.
llvm-svn: 234300
|
|
Before:
A a = new A(){public String toString(){return "NotReallyA";
}
}
;
After:
A a = return new A() {
public String toString() {
return "NotReallyA";
}
};
This fixes llvm.org/PR22878.
llvm-svn: 232042
|
|
Before:
try
(SomeResource rs = someFunction()) {
Something();
}
After:
try (SomeResource rs = someFunction()) {
Something();
}
llvm-svn: 225973
|
|
Before:
boolean someFunction(@Param(aaaaaaaaaaaaaaaa)
String aaaaa,
String bbbbbbbbbbbbbbb) {}
After:
boolean someFunction(
@Param(aaaaaaaaaaaaaaaa) String aaaaa,
String bbbbbbbbbbbbbbb) {}
llvm-svn: 225971
|
|
llvm-svn: 225965
|
|
Before:
@Test
ReturnType
doSomething(String aaaaaaaaaaaaa, String bbbbbbbbbbbbbbb) {}
After:
@Test
ReturnType doSomething(
String aaaaaaaaaaaaa, String bbbbbbbbbbbbbbb) {}
llvm-svn: 225964
|
|
Before:
@SomeAnnotation
(aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa)
int i;
After:
@SomeAnnotation(
aaaaaaaaaaaaaaaaa, aaaaaaaaaaaaaaaaaaaa)
int i;
llvm-svn: 225963
|
|
Before:
@Test(a)
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa = aaaaaaaaaaaaaaaaaaaaaaaaaaaa(
aaaaaaaaaaaaaaaaaaaaaaa);
After:
@Test(a)
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa =
aaaaaaaaaaaaaaaaaaaaaaaaaaaa(aaaaaaaaaaaaaaaaaaaaaaa);
llvm-svn: 225962
|
|
Before:
public native<X> Foo foo();
After:
public native <X> Foo foo();
llvm-svn: 225839
|
|
llvm-svn: 225559
|
