This is a short-term fix for PR33650 aimed to get the modules build bots green again.
Remove all the places where we use the LLVM_YAML_IS_(FLOW_)?SEQUENCE_VECTOR
macros to try to locally specialize a global template for a global type. That's
not how C++ works.
Instead, we now centrally define how to format vectors of fundamental types and
of string (std::string and StringRef). We use flow formatting for the former
cases, since that's the obvious right thing to do; in the latter case, it's
less clear what the right choice is, but flow formatting is really bad for some
cases (due to very long strings), so we pick block formatting. (Many of the
cases that were using flow formatting for strings are improved by this change.)
Other than the flow -> block formatting change for some vectors of strings,
this should result in no functionality change.
Differential Revision: https://reviews.llvm.org/D34907
Corresponding LLVM change is r306878.
llvm-svn: 306881
Summary:
This patch introduces a few extra BraceWrapping options, similar to
`SplitEmptyFunction`, to allow merging empty 'record' bodies (e.g.
class, struct, union and namespace):
* SplitEmptyClass
* SplitEmptyStruct
* SplitEmptyUnion
* SplitEmptyNamespace
The `SplitEmptyFunction` option name has also been simplified/
shortened (from `SplitEmptyFunctionBody`).
These options are helpful when the correspond AfterXXX option is
enabled, to allow merging the empty record:
class Foo
{};
In addition, this fixes an unexpected merging of short records, when
the AfterXXXX options are used, which caused to be formatted like
this:
class Foo
{ void Foo(); };
This is now properly formatted as:
class Foo
{
void Foo();
};
Reviewers: djasper, krasimir
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D34395
llvm-svn: 306874
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
This is a more principled version of r303756. That change was both very
brittle about the state of the Diags object going into the driver and
also broke tooling in funny ways.
In particular it prevented tools from capturing diagnostics properly and
made the compilation database logic fail to provide arguments to the
tool, falling back to scanning directories for JSON files.
llvm-svn: 306822
improve support for LLVM-style include sorting.
This really is a collection of improvements to the rules for LLVM
include sorting:
- We have gmock headers now, so it adds support for those to one of the
categories.
- LLVM does use 'FooTest.cpp' files to test 'Foo.h' so it adds that
suffix for finding a main header.
- At times the test file's case may not match the header file's case, so
switch to case-insensitive regex matching of header names.
With this set of changes, I can't spot any misbehaviors when re-sorting
all of LLVM's unittest '#include' lines.
Thanks to Eric and Daniel for help testing and refining the patch during
review!
Differential Revision: https://reviews.llvm.org/D33932
llvm-svn: 306759
Summary:
This patch makes the `{` in `msg_field{field: OK}` in a proto option scope be
treated as an assignment operator. Previosly the added test case was formatted
as:
```
option (MyProto.options) = {
field_a: OK
field_b{field_c: OK} field_d: OKOKOK field_e: OK
}
```
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D34749
llvm-svn: 306672
arguments when `-fsyntax-only` is used
Previously, Clang failed to create a fixed compilation database when the
compilation arguments use -fsyntax-only instead of -c. This commit fixes the
issue by forcing Clang to look at the compilation job when stripping the
positional arguments.
Differential Revision: https://reviews.llvm.org/D34687
llvm-svn: 306659
Summary:
This patch adds support for <>-style proto message fields inside proto options.
Previously these were wrongly treated as binary operators and as such were
working only by chance for a limited number of cases.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D34621
llvm-svn: 306406
... once each for the syntactic and semantic form. Without this fix, behavior
of the newly added tests would have been
InitListExprIsPreOrderVisitedTwice:
syntactic: 1
semantic: 2
InitListExprIsPostOrderVisitedTwice:
syntactic: 0
semantic: 1
InitListExprIsPreOrderNoQueueVisitedTwice:
syntactic: 1
semantic: 2
InitListExprIsPostOrderNoQueueVisitedTwice:
syntactic: 0
semantic: 2
llvm-svn: 306374
...instead of -std=c99, as the latter lead to
error: invalid argument '-std=c99' not allowed with 'C++'
complaints in test logs
Differential Revision: https://reviews.llvm.org/D34417
llvm-svn: 306373
Summary:
This is the same as Inline, except it does not imply all empty
functions are merged: with this style, empty functions are merged only
if they also match the 'inline' criteria (i.e. defined in a class).
This is helpful to avoid inlining functions in implementations files.
Reviewers: djasper, krasimir
Reviewed By: djasper
Subscribers: klimek, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D34399
llvm-svn: 305912
Summary:
This fixes the missing space before the designated initializer when `Cpp11BracedListStyle=false` :
const struct A a = { .a = 1, .b = 2 };
^
Also, wrapping between opening brace and designated array initializers used to have an excessive penalty (like breaking between an expression and the subscript operator), leading to unexpected wrapping:
const struct Aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaa =
{[1] = aaaaaaaaaaaaaaaaaaaaaaaaaaa,
[2] = bbbbbbbbbbbbbbbbbbbbbbbbbbb};
instead of:
const struct Aaaaaaaaaaaaaaaa aaaaaaaaaaaaaaaaaa = {
[1] = aaaaaaaaaaaaaaaaaaaaaaaaaaa,
[2] = bbbbbbbbbbbbbbbbbbbbbbbbbbb};
Finally, designated array initializers are not binpacked, just like designated member initializers.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, krasimir, klimek
Differential Revision: https://reviews.llvm.org/D33491
llvm-svn: 305696
Fixes an issue where struct A { int X; }; would be broken onto multiple
lines, but typedef struct A { int X; } A2; was collapsed onto a single
line.
Patch by Jacob Bandes-Storch. Thank you.
llvm-svn: 305667
c++1z adds the following constructions to the language:
if constexpr (cond)
statement1;
else if constexpr (cond)
statement2;
else if constexpr (cond)
statement3;
else
statement4;
A first version of this was proposed in reviews.llvm.org/D26953 by
Francis Visoiu Mistrih, but never commited. This patch additionally
fixes the behavior when allowing short if statements on a single line
and was authored by Jacob Bandes-Storch. Thank you to both authors.
llvm-svn: 305666
A new LexerTest unittest introduced a memory leak. This patch
uses a unique_ptr with a custom deleter to ensure it is properly
deleted.
llvm-svn: 305491
correct getNumArguments
StringifiedArguments is allocated (resized) based on the size the
getNumArguments function. However, this function ACTUALLY currently
returns the amount of total UnexpArgTokens which is minimum the same as
the new implementation of getNumMacroArguments, since empty/omitted arguments
result in 1 UnexpArgToken, and included ones at minimum include 2
(1 for the arg itself, 1 for eof).
This patch renames the otherwise unused getNumArguments to be more clear
that it is the number of arguments that the Macro expects, and thus the maximum
number that can be stringified. This patch also replaces the explicit memset
(which results in value instantiation of the new tokens, PLUS clearing the
memory) with brace initialization.
Differential Revision: https://reviews.llvm.org/D32046
llvm-svn: 305425
Summary:
Add CompactNamespaces option, to pack namespace declarations on the
same line (somewhat similar to C++17 nested namespace definition).
With this option, consecutive namespace declarations are kept on the
same line:
namespace foo { namespace bar {
...
}} // namespace foo::bar
Reviewers: krasimir, djasper, klimek
Reviewed By: djasper
Subscribers: kimgr, cfe-commits, klimek
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D32480
llvm-svn: 305384
Summary:
This option supplements the AllowShortFunctionsOnASingleLine flag, to
merge empty function body at the beginning of the line: e.g. when the
function is not short-enough and breaking braces after function.
int f()
{}
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33447
llvm-svn: 305272
as part of a compilation.
This is intended for two purposes:
1) Writing self-contained test cases for modules: we can now write a single
source file test that builds some number of module files on the side and
imports them.
2) Debugging / test case reduction. A single-source testcase is much more
amenable to reduction, compared to a VFS tarball or .pcm files.
llvm-svn: 305101
No-one was using this, and it's not meaningful in general -- FrontendActions
can be run on inputs that don't have a corresponding source file. The current
frontend input can be obtained by asking the FrontendAction if any future
action actually needs it.
llvm-svn: 305045
r305022 assumed that floatLiteral(equals(1.2)) would also match 1.2f and
1.2l, but apparently that is not the case. Until it is clear how to
match, temporary disable the test to fix CI.
llvm-svn: 305025
Summary:
This allows the clang-query tool to use matchers like
"integerLiteral(equals(32))". For this to work, an overloaded function
is added for each possible parameter type.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D33094
llvm-svn: 305022
Summary:
Needed to support something like "floatLiteral(equals(1.0))". The
parser for floating point numbers is kept simple, so instead of ".1" you
have to use "0.1".
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D33135
llvm-svn: 305021
Summary:
Recognize boolean literals for future extensions ("equals(true)").
Note that a specific VariantValue constructor is added to resolve
ambiguity (like "Value = 5") between unsigned and bool.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D33093
llvm-svn: 305020
Summary:
This patch is a follow-up of https://reviews.llvm.org/rL304687, which fixed an
overflow in the comment alignment code in clang-format. The token length of
trailing comments of preprocessor directives is calculated incorrectly by
including the text between consecutive directives. That causes them to not being
aligned.
For example, in this code with column limit 20
```
#if A
#else // A
int iiii;
#endif // B
```
the length of the token `// A` was wrongly calculated as 14 = 5 (the size of `// A\n`) plus 9 (the size of `int iiii;`) and so `// A` wouldn't be aligned with `// B` and this was produced:
```
#if A
#else // A
int iiii;
#endif // B
```
This patch fixes this case.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33982
llvm-svn: 304912
Summary: Support "export type T = {...};", in addition to just "type T = {...};".
Reviewers: klimek
Differential Revision: https://reviews.llvm.org/D33980
llvm-svn: 304904
Nested literals are sometimes only indented by 2 spaces, instead of
respecting the IndentWidth option.
There are existing unit tests (FormatTestJS.ArrayLiterals) that only
pass because the style used to test them uses an IndentWidth of 2.
This change removes the magic 2 and always uses the IndentWidth.
I've added 6 tests. The first 4 of these tests fail before this change,
while the last 2 already pass, but were added just to make sure it the
change works with all types of braces.
Patch originally by Jared Neil, thanks!
Differential Revision: https://reviews.llvm.org/D33857
llvm-svn: 304791
Summary:
This patch fixes a bug where clang-format will align newly broken trailing
comments even if this will make them exceed the line limit. The bug was caused
by a combination of unsigned arithmetic overflow and an imprecise computation
of the length of broken comment lines.
Reviewers: djasper, alexfh
Reviewed By: alexfh
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D33830
llvm-svn: 304687
Summary:
calculateBraceTypes decides for braced init for empty brace pairs ({}).
In context of a function declaration, this incorrectly classifies empty
function or method bodies as braced inits, leading to missing wraps:
class C {
foo() {}[bar]() {}
}
Where code should have wrapped after "}", before "[". This change adds
another piece of contextual information in that braces following closing
parentheses must always be the opening braces of function blocks. This
fixes brace detection for methods immediately followed by brackets
(computed property declarations), but also curlies.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33714
llvm-svn: 304290
Summary:
In JavaScript, duplicated commas have semantic meaning.
x = [a,,b];
The statement above creates an array with three entries, the middle being undefined. Because clang-format should not change semantics, disable this cleanup in JS.
Reviewers: djasper
Subscribers: klimek
Differential Revision: https://reviews.llvm.org/D33641
llvm-svn: 304141
Summary:
The previous fix to force build style wrapping if the previous token is a closing parenthesis broke a peculiar pattern where users parenthesize the function declaration in a bind call:
fn((function() { ... }).bind(this));
This restores the previous behaviour by reverting that change, but narrowing the special case for unindenting closing parentheses to those followed by semicolons and opening braces, i.e. immediate calls and function declarations.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33640
llvm-svn: 304135
This is recommit of r302775, reverted in r302777 due to a fail in
clang-tidy. Original mesage is below.
Now if clang driver is given wrong arguments, in some cases it
continues execution and returns zero code. This change fixes this
behavior.
The fix revealed some errors in clang test set.
File test/Driver/gfortran.f90 added in r118203 checks forwarding
gfortran flags to GCC. Now driver reports error on this file, because
the option -working-directory implemented in clang differs from the
option with the same name implemented in gfortran, in clang the option
requires argument, in gfortran does not.
In the file test/Driver/arm-darwin-builtin.c clang is called with
options -fbuiltin-strcat and -fbuiltin-strcpy. These option were removed
in r191435 and now clang reports error on this test.
File arm-default-build-attributes.s uses option -verify, which is not
supported by driver, it is cc1 option.
Similarly, the file split-debug.h uses options -fmodules-embed-all-files
and -fmodule-format=obj, which are not supported by driver.
Other revealed errors are mainly mistypes.
Differential Revision: https://reviews.llvm.org/D33013
llvm-svn: 303756
Now FixedCompilationDatabase::loadFromCommandLine has no means to report
which error occurred if it fails to create compilation object. This is
a block for implementing D33013, because after that change driver will
refuse to create compilation if command line contains erroneous options.
This change adds additional argument to loadFromCommandLine, which is
assigned error message text if compilation object was not created. This is
the same way as other methods of CompilationDatabase report failure.
Differential Revision: https://reviews.llvm.org/D33272
llvm-svn: 303741
Summary:
This option replaces the BreakConstructorInitializersBeforeComma option with an enum, thus introducing a mode where the colon stays on the same line as constructor declaration:
// When it fits on line:
Constructor() : initializer1(), initializer2() {}
// When it does not fit:
Constructor() :
initializer1(), initializer2()
{}
// When ConstructorInitializerAllOnOneLineOrOnePerLine = true:
Constructor() :
initializer1(),
initializer2()
{}
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32479
llvm-svn: 303739
The change that enabled wrapping at the previous scope's indentation had
unintended side-effects in that clang-format would prefer to wrap
closing parentheses to the next line if it avoided a wrap on the next
line (assuming very narrow lines):
fooObject
.someCall(barbazbam)
.then(bam);
Would get formatted as:
fooObject.someCall(barbazbam
).then(bam);
Because the ')' is now indented at the parent level (fooObject).
Normally formatting a builder pattern style call sequence like that is
outlawed in clang-format anyway. However for JavaScript this is special
cased to support trailing .bind calls.
This change disallows this special case when following a closing ')' to
avoid the problem.
Included are some random comment fixes.
Reviewers: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33399
llvm-svn: 303557
Summary:
This patch prevents reflowing bullet lists in block comments.
It handles all lists supported by doxygen and markdown, e.g. bullet
lists starting with '-', '*', '+', as well as numbered lists starting
with -# or a number followed by a dot.
Reviewers: krasimir
Reviewed By: krasimir
Subscribers: djasper, klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33285
llvm-svn: 303556
Summary:
r303415 changed the way a sequence of line comments following a preprocessor
macro is handled, which has the unfortunate effect of aligning a trailing
preprocessor line comment and following unrelated section comments, so:
```
#ifdef A // comment about A
// section comment
#endif
```
gets turned into:
```
#ifdef A // comment about A
// section comment
#endif
```
This patch fixes this by additionally checking the original start columns of
the line comments.
Reviewers: djasper
Reviewed By: djasper
Subscribers: klimek, cfe-commits
Differential Revision: https://reviews.llvm.org/D33394
llvm-svn: 303541
Summary:
Add option to customize the penalty for breaking assignment
This allows increasing the priority of the assignment, to prefer spliting
an operation instead of splitting the assignment, e.g. :
int a = bbbbbbbbbbbbbbbb +
cccccccccccccccc;
Reviewers: krasimir, djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D32477
llvm-svn: 303534
Summary:
This patch updates the handling of multiline trailing comment sections in
import statement lines to make it more consistent with the case in general.
This includes updating the parsing logic to collect the trailing comment
sections and the formatting logic to not insert escaped newlines at the end of
comment lines in import statement lines.
Specifically, before this patch this code:
```
#include <a> // line 1
// line 2
```
will be turned into two unwrapped lines, whereas this code:
```
int i; // line 1
// line 2
```
is turned into a single unwrapped line, enabling reflowing across comments.
An example where the old behaviour is bad is when partially formatting the lines
3 to 4 of this code:
```
#include <a> // line 1
// line 2
int i;
```
which gets turned into:
```
#include <a> // line 1
// line 2
int i;
```
because the two comment lines were independent and the indent was copied.
Reviewers: djasper
Reviewed By: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33351
llvm-svn: 303415
Summary:
The syntax is actually `for await (const x of y)` (d'oh).
This also fixes a crash for `for` tokens not followed by additional tokens.
Reviewers: djasper
Subscribers: cfe-commits, klimek
Differential Revision: https://reviews.llvm.org/D33329
llvm-svn: 303382
Richard Smith