summaryrefslogtreecommitdiffstats
path: root/clang/lib/Format/UnwrappedLineParser.cpp
Commit message (Collapse)AuthorAgeFilesLines
* [clang-format] Fix a clang-tidy finding, NFCKrasimir Georgiev2017-11-091-1/+1
| | | | llvm-svn: 317784
* [clang-format] Format raw string literalsKrasimir Georgiev2017-10-301-2/+7
| | | | | | | | | | | | | | | Summary: This patch adds raw string literal formatting. Reviewers: djasper, klimek Reviewed By: klimek Subscribers: klimek, mgorny Differential Revision: https://reviews.llvm.org/D35943 llvm-svn: 316903
* clang-format clang-format.Manuel Klimek2017-09-201-18/+16
| | | | llvm-svn: 313744
* Fix clang-format's detection of structured bindings.Manuel Klimek2017-09-201-11/+8
| | | | | | | | | | | | | | | | | | | Correctly determine when [ is part of a structured binding instead of a lambda. To be able to reuse the implementation already available, this patch also: - sets the Previous link of FormatTokens in the UnwrappedLineParser - moves the isCppStructuredBinding function into FormatToken Before: auto const const &&[x, y] { A *i }; After: auto const const && [x, y]{A * i}; Fixing formatting of the type of the structured binding is still missing. llvm-svn: 313742
* Fix formatting of lambda introducers with initializers.Manuel Klimek2017-09-191-53/+15
| | | | | | | | | | | | | | | | | | | | | Most of the work was already done when we introduced a look-behind based lambda introducer detection. This patch finishes the transition by completely relying on the simple lambda introducer detection and simply recursing into normal brace-parsing code to parse until the end of the introducer. This fixes initializers in lambdas, including nested lambdas. Before: auto a = [b = [c = 42]{}]{}; auto b = [c = &i + 23]{}; After: auto a = [b = [c = 42] {}] {}; auto b = [c = &i + 23] {}; llvm-svn: 313622
* [clang-format] New flag - BraceWrapping.AfterExternBlockKrasimir Georgiev2017-09-151-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Bug: https://bugs.llvm.org/show_bug.cgi?id=34016 - **"extern C part"** **Problem:** Due to the lack of "brace wrapping extern" flag, clang format does parse the block after **extern** keyword moving the opening bracket to the header line always! **Patch description:** A new style added, new configuration flag - **BraceWrapping.AfterExternBlock** that allows us to decide whether we want a break before brace or not. Reviewers: djasper, krasimir Reviewed By: krasimir Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D37845 Contributed by @PriMee! llvm-svn: 313354
* clang-format: Fix indentation of macros in include guards (after r312125).Daniel Jasper2017-09-041-4/+3
| | | | | | | | | | | | | | | | | | | | | | | | Before: #ifndef A_H #define A_H #define A() \ int i; \ int j; #endif // A_H After: #ifndef A_H #define A_H #define A() \ int i; \ int j; #endif // A_H llvm-svn: 312484
* clang-format: Add preprocessor directive indentationKrasimir Georgiev2017-08-301-3/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is an implementation for [bug 17362](https://bugs.llvm.org/attachment.cgi?bugid=17362) which adds support for indenting preprocessor statements inside if/ifdef/endif. This takes previous work from fmauch (https://github.com/fmauch/clang/tree/preprocessor_indent) and makes it into a full feature. The context of this patch is that I'm a VMware intern, and I implemented this because VMware needs the feature. As such, some decisions were made based on what VMware wants, and I would appreciate suggestions on expanding this if necessary to use-cases other people may want. This adds a new enum config option, `IndentPPDirectives`. Values are: * `PPDIS_None` (in config: `None`): ``` #if FOO #if BAR #include <foo> #endif #endif ``` * `PPDIS_AfterHash` (in config: `AfterHash`): ``` #if FOO # if BAR # include <foo> # endif #endif ``` This is meant to work whether spaces or tabs are used for indentation. Preprocessor indentation is independent of indentation for non-preprocessor lines. Preprocessor indentation also attempts to ignore include guards with the checks: 1. Include guards cover the entire file 2. Include guards don't have `#else` 3. Include guards begin with ``` #ifndef <var> #define <var> ``` This patch allows `UnwrappedLineParser::PPBranchLevel` to be decremented to -1 (the initial value is -1) so the variable can be used for indent tracking. Defects: * This patch does not handle the case where there's code between the `#ifndef` and `#define` but all other conditions hold. This is because when the #define line is parsed, `UnwrappedLineParser::Lines` doesn't hold the previous code line yet, so we can't detect it. This is out of the scope of this patch. * This patch does not handle cases where legitimate lines may be outside an include guard. Examples are `#pragma once` and `#pragma GCC diagnostic`, or anything else that does not change the meaning of the file if it's included multiple times. * This does not detect when there is a single non-preprocessor line in front of an include-guard-like structure where other conditions hold because `ScopedLineState` hides the line. * Preprocessor indentation throws off `TokenAnnotator::setCommentLineLevels` so the indentation of comments immediately before indented preprocessor lines is toggled on each run. Fixing this issue appears to be a major change and too much complexity for this patch. Contributed by @euhlmann! Reviewers: djasper, klimek, krasimir Reviewed By: djasper, krasimir Subscribers: krasimir, mzeren-vmw, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D35955 llvm-svn: 312125
* clang-format: [JS] detect ASI after closing parens.Martin Probst2017-08-091-1/+2
| | | | | | | | | | | | Summary: A closing parenthesis followed by a declaration or statement should always terminate the current statement. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D36491 llvm-svn: 310482
* clang-format: [JS] support fields with case/switch/default labels.Martin Probst2017-08-041-0/+14
| | | | | | | | | | | | | | | | | | | | | Summary: `case:` and `default:` would normally parse as labels for a `switch` block. However in TypeScript, they can be used in field declarations, e.g.: interface I { case: string; } This change special cases parsing them in declaration lines to avoid wrapping them. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D36148 llvm-svn: 310070
* [clang-format] Fix parsing of <>-style proto optionsKrasimir Georgiev2017-08-031-0/+9
| | | | | | | | | | | | | | | | | Summary: This patch fixes the parsing of proto option fields like `option op = <...>`. Previously the parser did not enter the right code path inside the angle braces, causing the contents to be split into several unwrapped lines inside. I'll just go ahead and commit this since it's a straightforward bugfix. Reviewers: djasper, klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D36217 llvm-svn: 309937
* clang-format: [JS] handle object types in extends positions.Martin Probst2017-08-011-0/+11
| | | | | | | | | | | | | | | | | Summary: clang-format would previously drop the whitespace after `extends` in code such as: class Foo extends {} {} Where the first set of curly braces is an inline object literal type. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D36131 llvm-svn: 309695
* clang-format: fix block OpeningLineIndex around preprocessorFrancois Ferrand2017-07-281-12/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current code would return an incorrect value when a preprocessor directive is present immediately after the opening brace: this causes the nanespace end comment fixer to break in some places, for exemple it would not add the comment in this case: namespace a { #define FOO } Fixing the computation is simple enough, but it was breaking a feature, as it would cause comments to be added also when the namespace declaration was dependant on conditional compilation. To fix this, a hash of the current preprocessor stack/branches is computed at the beginning of parseBlock(), so that we explicitely do not store the OpeningLineIndex when the beginning and end of the block are not in the same preprocessor conditions. Tthe hash is computed based on the line, but this could propbably be improved by using the actual condition, so that clang-format would be able to match multiple identical #ifdef blocks. Reviewers: krasimir, djasper Reviewed By: krasimir Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D35483 llvm-svn: 309369
* [clang-format] Reorder assignments, NFCKrasimir Georgiev2017-07-241-1/+1
| | | | llvm-svn: 308918
* [clang-format] Fix comment levels between '} else {' and PPDirective.Krasimir Georgiev2017-07-241-7/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes a regression exposed by r307795 and rL308725 in which the level of a comment line between '} else {' and a preprocessor directive is incorrectly set as the level of the '} else {' line. For example, this : ``` int f(int i) { if (i) { ++i; } else { // comment #ifdef A --i; #endif } } ``` was formatted as: ``` int f(int i) { if (i) { ++i; } else { // comment #ifdef A --i; #endif } } ``` Reviewers: djasper, klimek Reviewed By: klimek Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D35794 llvm-svn: 308882
* [clang-format] Fix comment levels between '}' and PPDirectiveKrasimir Georgiev2017-07-211-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes a regression exposed by r307795 in which the level of a comment line between '}' and a preprocessor directive is incorrectly set as the level of the line before the '}'. In effect, this: ``` int f(int i) { int j = i; return i + j; } // comment #ifdef A #endif ``` was formatted as: ``` int f(int i) { int j = i; return i + j; } // comment #ifdef A #endif ``` Reviewers: djasper Reviewed By: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D35485 llvm-svn: 308725
* clang-format: [JS] Correctly format JavaScript imports with long module pathsMartin Probst2017-07-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Currently the `UnwrappedLineParser` fails to correctly unwrap JavaScript imports where the module path is not on the same line as the `from` keyword. For example: import {A} from 'some/path/longer/than/column/limit/module.js';``` This causes issues when in the middle a list of imports because the formatter thinks it has reached the end of the imports, and therefore will not sort any imports lower in the list. The formatter will, however, split the `from` keyword and the module path if the path exceeds the column limit, which triggers the issue the next time the file is formatted. Patch originally by Jared Neil - thanks! Differential Revision: https://reviews.llvm.org/D34920 llvm-svn: 308306
* [clang-format] Support text proto messagesKrasimir Georgiev2017-07-031-8/+25
| | | | | | | | | | | | | | Summary: This patch adds support for textual protocol buffer messages. Reviewers: djasper Reviewed By: djasper Subscribers: cfe-commits, klimek, mgorny Differential Revision: https://reviews.llvm.org/D34441 llvm-svn: 307029
* [clang-format] Fix a buildbot failure after r306406Krasimir Georgiev2017-06-271-1/+2
| | | | llvm-svn: 306408
* [clang-format] Support <>-style proto message fieldsKrasimir Georgiev2017-06-271-6/+10
| | | | | | | | | | | | | | | | | 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
* clang-format: Handle "if constexpr".Daniel Jasper2017-06-191-0/+2
| | | | | | | | | | | | | | | | | | | | 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
* clang-format: Add CompactNamespaces optionFrancois Ferrand2017-06-141-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* clang-format: [JS] improve calculateBraceType heuristicMartin Probst2017-05-311-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [clang-format] Keep trailing preprocessor line comments separate from the ↵Krasimir Georgiev2017-05-221-14/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | following section comments 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
* [clang-format] Handle trailing comment sections in import statement linesKrasimir Georgiev2017-05-191-7/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* clang-format: [JS] for await, and fix a crash with for loops.Martin Probst2017-05-181-2/+2
| | | | | | | | | | | | | | 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
* [clang-format] Fix MatchingOpeningBlockLineIndex computationKrasimir Georgiev2017-05-181-2/+3
| | | | | | | | | | | | | | | | | | | | | | Summary: Computed line index must be relative to the current 'parent' node, and thus use CurrentLines instead of Lines. Without this, a child line's MatchingOpeningBlockLineIndex is out of range of the parent's list of line, which can cause crash or unexpected behavior if this field is used in childs. Contributed by @Typz! Reviewers: krasimir, djasper Reviewed By: krasimir Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D32524 llvm-svn: 303353
* clang-format: [JS] for async loops.Martin Probst2017-05-151-0/+4
| | | | | | | | | | | | | | | Summary: JavaScript supports asynchronous loop iteration in async functions: for async (const x of y) ... Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D33193 llvm-svn: 303106
* clang-format: refine calculating brace types.Martin Probst2017-05-101-1/+2
| | | | | | | | | | | | | | | | | | Summary: For C++ code, opening parenthesis following a } indicate a braced init. For JavaScript and other languages, this is an invalid syntactical construct, unless the closing parenthesis belongs to a function - in which situation its a BK_Block. This fixes indenting IIFEs following top level functions: function foo() {} (function() { codeHere(); }()); clang-format used to collapse these lines together. Subscribers: klimek Differential Revision: https://reviews.llvm.org/D33006 llvm-svn: 302658
* clang-format: [JS] Don't indent JavaScript IIFEs.Martin Probst2017-05-091-4/+23
| | | | | | | | | | | | | | | | Because IIFEs[1] are often used like an anonymous namespace around large sections of JavaScript code, it's useful not to indent to them (which effectively reduces the column limit by the indent amount needlessly). It's also common for developers to wrap these around entire files or libraries. When adopting clang-format, changing the indent entire file can reduce the usefulness of the blame annotations. Patch by danbeam, thanks! Differential Revision: https://reviews.llvm.org/D32989 llvm-svn: 302580
* clang-format: [JS] parse async function declarations.Martin Probst2017-04-271-6/+8
| | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, clang-format would accidentally parse an async function declaration as a function expression, and thus not insert an unwrapped line for async functions, causing subsequent functions to run into the function: async function f() { x(); } function g() { ... With this change, async functions get parsed as top level function declarations and get their own unwrapped line context. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D32590 llvm-svn: 301538
* clang-format: Fix post-commit review comment of r299204, use Style.isCpp().Daniel Jasper2017-03-311-5/+4
| | | | | | Also, while at it, s/IsCpp/isCpp/ so that it follows LLVM style. llvm-svn: 299214
* clang-format: [JavaScript] Ignore QT keywords.Daniel Jasper2017-03-311-1/+3
| | | | llvm-svn: 299204
* [clang-format] Use a reference in loop variable; NFCKrasimir Georgiev2017-03-101-1/+1
| | | | llvm-svn: 297455
* [clang-format] Don't add namespace end comments for unbalanced right braces ↵Krasimir Georgiev2017-03-011-0/+1
| | | | | | after namespace end llvm-svn: 296638
* Fix r296605 so that stuff in #ifndef SWIG blocks is still formatted.Daniel Jasper2017-03-011-1/+2
| | | | llvm-svn: 296608
* clang-format: Ignore contents of #ifdef SWIG .. #endif blocks.Daniel Jasper2017-03-011-6/+6
| | | | | | | | Those blocks are used if C++ code is SWIG-wrapped (see swig.org) and usually do not contain C++ code. Also cleanup the implementation of for #if 0 and #if false a bit. llvm-svn: 296605
* [clang-format] Add a NamespaceEndCommentsFixerKrasimir Georgiev2017-02-271-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds a NamespaceEndCommentsFixer TokenAnalyzer for clang-format, which fixes end namespace comments. It currently supports inserting and updating existing wrong comments. Example source: ``` namespace A { int i; } namespace B { int j; } // namespace A ``` after formatting: ``` namespace A { int i; } // namespace A namespace B { int j; } // namespace B ``` Reviewers: klimek, djasper Reviewed By: djasper Subscribers: klimek, mgorny Differential Revision: https://reviews.llvm.org/D30269 llvm-svn: 296341
* clang-format: Fix many Objective-C formatting regressions from r289428Nico Weber2017-02-241-4/+3
| | | | | | | | | | | | | | | r289428 added a separate language kind for Objective-C, but kept many "Language == LK_Cpp" checks untouched. This introduced a "IsCpp()" method that returns true for both C++ and Objective-C++, and replaces all comparisons of Language with LK_Cpp with calls to this new method. Also add a lot more test coverge for formatting things in LK_ObjC mode, by having FormatTest's verifyFormat() test for LK_ObjC everything that's being tested for LK_Cpp at the moment. Fixes PR32060 and many other things. llvm-svn: 296160
* [clang-format] Break before a sequence of line comments aligned with the ↵Krasimir Georgiev2017-02-081-12/+67
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | next line. Summary: Make the comment alignment respect sections of line comments originally alinged with the next token. Until now the decision how to break a continuous sequence of line comments into sections was taken without reference to the next token. source: ``` class A { public: // comment about public // comment about a int a; } ``` format before: ``` class A { public: // comment about public // comment about a int a; } ``` format after: ``` class A { public: // comment about public // comment about a int a; } ``` Reviewers: djasper, klimek Reviewed By: klimek Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D29626 llvm-svn: 294435
* clang-format: [JS] correcly format object literal methods.Martin Probst2017-02-071-8/+17
| | | | | | | | | | | | | | | | | | | | | Summary: In JavaScript, object literals can contain methods: var x = { a() { return 1; }, }; Previously, clang-format always parsed nested {} inside a braced list as further braced lists. Special case this logic for JavaScript to try parsing as a braced list, but fall back to parsing as a child block. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D29656 llvm-svn: 294315
* clang-format: [JS] handle parenthesized class expressions.Martin Probst2017-02-071-5/+15
| | | | | | | | | | | | | | | | | | | | Summary: In JavaScript, classes are expressions, so they can appear e.g. in argument lists. var C = foo(class { bar() { return 1; } }; Reviewers: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D29635 llvm-svn: 294302
* [clang-format] Don't reflow across comment pragmas.Krasimir Georgiev2017-02-021-4/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The comment reflower wasn't taking comment pragmas as reflow stoppers. This patch fixes that. source: ``` // long long long long // IWYU pragma: ``` format with column limit = 20 before: ``` // long long long // long IWYU pragma: ``` format with column limit = 20 after: ``` // long long long // long // IWYU pragma: ``` Reviewers: djasper Reviewed By: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D29450 llvm-svn: 293898
* [clang-format] Fix breaking of comment sections in unwrapped lines ↵Krasimir Georgiev2017-02-021-2/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | containing newlines. Summary: The breaking of line comment sections was misaligning the case where the first comment line is on an unwrapped line containing newlines. In this case, the breaking column must be based on the source column of the last token that is preceded by a newline, not on the first token of the unwrapped line. source: ``` enum A { a, // line 1 // line 2 }; ``` format before: ``` enum A { a, // line 1 // line 2 }; ``` format after: ``` enum A { a, // line 1 // line 2 }; ``` Reviewers: djasper Reviewed By: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D29444 llvm-svn: 293891
* [clang-format] Fix regression merging comments across newlines.Krasimir Georgiev2017-01-311-1/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This fixes a regression that causes example: ``` enum A { a, // line a // line b b }; ``` to be formatted as follows: ``` enum A { a, // line a // line b b }; ``` Reviewers: djasper, klimek Reviewed By: klimek Subscribers: cfe-commits, sammccall, djasper, klimek Differential Revision: https://reviews.llvm.org/D29322 llvm-svn: 293624
* [clang-format] Separate line comment sections after a right brace from ↵Krasimir Georgiev2017-01-301-7/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | comment sections in the scope. Summary: The following two comment lines form a single comment section: ``` if (1) { // line 1 // line 2 } ``` This is because the break of a comment section was based on the original column of the first token of the previous line (in this case, the 'if'). This patch splits these two comment lines into different sections by taking into account the original column of the right brace preceding the first line comment where applicable. Reviewers: djasper Reviewed By: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D29291 llvm-svn: 293539
* [clang-format] Implement comment reflowing.Krasimir Georgiev2017-01-251-3/+53
| | | | | | | | | | | | | | | | | | Summary: This presents a version of the comment reflowing with less mutable state inside the comment breakable token subclasses. The state has been pushed into the driving breakProtrudingToken method. For this, the API of BreakableToken is enriched by the methods getSplitBefore and getLineLengthAfterSplitBefore. Reviewers: klimek Reviewed By: klimek Subscribers: djasper, klimek, mgorny, cfe-commits, ioeric Differential Revision: https://reviews.llvm.org/D28764 llvm-svn: 293055
* clang-format: [JS] revert over-eager ASI check.Martin Probst2017-01-161-2/+1
| | | | | | | | | | | | Summary: Change r291428 introduced ASI detection after closing curly braces. That would generally be correct, however this breaks indentation for structural statements. What happens is that CompoundStatementIndenter increases indentation for the current line, then after reading ASI creates a new line (with the increased line level), and only after the structural parser sees e.g. the if/then/else branch closed, line level is reduced. That leads to the new line started by ASI having a level too high. Reviewers: djasper Subscribers: sammccall, cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D28763 llvm-svn: 292099
* clang-format: [JS] ASI after importsMartin Probst2017-01-091-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Automatic semicolon insertion should break import and export statements: Before, this would format on one line: // Note: no semi after 'x' below! import {x} from 'x' export function foo() {} Into: import {x} from 'x' export function foo() {} With this change, the statements get separated. This also improves automatic semicolon insertion to consider closing braces preceding declarations and statements. Reviewers: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D28465 llvm-svn: 291428
* clang-format: [JS] avoid indent after ambient function declarations.Martin Probst2017-01-041-1/+4
| | | | | | | | | | | | | | | | | | | | | Summary: Before: declare function foo(); let x = 1; After: declare function foo(); let x = 1; The problem was that clang-format would unconditionally try to parse a child block, even though ambient function declarations do not have a body (similar to forward declarations). Reviewers: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D28246 llvm-svn: 290959
OpenPOWER on IntegriCloud