summaryrefslogtreecommitdiffstats
path: root/clang/lib/Format/TokenAnnotator.cpp
Commit message (Collapse)AuthorAgeFilesLines
* clang-format: [JS] handle `as const`.Martin Probst2019-08-261-0/+4
| | | | | | | | | | | | | | | | | | | | Summary: TypeScript 3.4 supports casting into a const type using `as const`: const x = {x: 1} as const; Previously, clang-format would insert a space after the `const`. With this patch, no space is inserted after the sequence `as const`. Reviewers: krasimir Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D66736 llvm-svn: 369916
* [clang-format] Fix a bug that joins template closer and =Owen Pan2019-08-181-1/+1
| | | | | | | | | | Also fixes the documentation for SpaceBeforeAssignmentOperators. See discussions at https://reviews.llvm.org/D66332 Differential Revision: https://reviews.llvm.org/D66384 llvm-svn: 369214
* [clang-format] Fix the bug that joins template closer and > or >>Owen Pan2019-08-161-0/+2
| | | | | | | | | | Also fixes a buggy test case. See PR42404 Differential Revision: https://reviews.llvm.org/D66332 llvm-svn: 369157
* [clang-format] Expand AllowShortBlocksOnASingleLine for WebKitOwen Pan2019-08-111-1/+2
| | | | | | | | See PR40840 Differential Revision: https://reviews.llvm.org/D66059 llvm-svn: 368539
* [clang-format] fix crash involving invalid preprocessor lineKrasimir Georgiev2019-08-081-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This (invalid) fragment is crashing clang-format: ``` #if 1 int x; #elif int y; #endif ``` The reason being that the parser expects a token after `#elif`, and the subsequent parsing of the next line does not check if `CurrentToken` is null. Reviewers: gribozavr Reviewed By: gribozavr Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65940 llvm-svn: 368280
* clang-format: Support `if CONSTEXPR` if CONSTEXPR is a macro.Nico Weber2019-07-271-7/+8
| | | | | | | | | | | | | | | | | | | | | | This is like r305666 (which added support for `if constexpr`) except that it allows a macro name after the if. This is slightly tricky for two reasons: 1. r305666 didn't add test coverage for all cases where it added a kw_constexpr, so I had to figure out what all the added cases were for. I now added tests for all `if constexpr` bits that didn't have tests. (This took a while, see e.g. https://reviews.llvm.org/D65223) 2. Parsing `if <ident> (` as an if means that `#if defined(` and `#if __has_include(` parse as ifs too. Add some special-case code to prevent this from happening where it's incorrect. Fixes PR39248. Differential Revision: https://reviews.llvm.org/D65227 llvm-svn: 367167
* [Format] Make it easy to add new format::FormatStyle::LanguageStandard. NFCIFangrui Song2019-07-241-2/+2
| | | | | | | | | | | | | | Preparatory change for D65043. We current use `!=LS_Cpp03` to enable language standards 11,14,17, and 2a. `>=LS_Cpp11` is better if we decide to add new LanguageStandard in the future. Reviewed By: sammccall Differential Revision: https://reviews.llvm.org/D65183 llvm-svn: 366876
* [Format/ObjC] Avoid breaking between unary operators and operandsBen Hamilton2019-07-191-0/+2
| | | | | | | | | | | | | | | | | | | | Summary: Test Plan: New tests added. Ran tests with: % ninja FormatTests && ./tools/clang/unittests/Format/FormatTests Confirmed tests failed before change and passed after change. Reviewers: krasimir, djasper, sammccall, klimek Reviewed By: sammccall Subscribers: klimek, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64775 llvm-svn: 366592
* [clang-format] Don't detect call to ObjC class method as C++11 attribute ↵Ben Hamilton2019-07-161-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | specifier Summary: Previously, clang-format detected something like the following as a C++11 attribute specifier. @[[NSArray class]] instead of an array with an Objective-C method call inside. In general, when the attribute specifier checking runs, if it sees 2 identifiers in a row, it decides that the square brackets represent an Objective-C method call. However, here, `class` is tokenized as a keyword instead of an identifier, so this check fails. To fix this, the attribute specifier first checks whether the first square bracket has an "@" before it. If it does, then that square bracket is not the start of a attribute specifier because it is an Objective-C array literal. (The assumption is that @[[.*]] is not valid C/C++.) Contributed by rkgibson2. Reviewers: benhamilton Reviewed By: benhamilton Subscribers: aaron.ballman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64632 llvm-svn: 366267
* clang-format: better handle namespace macrosFrancois Ferrand2019-06-061-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Other macros are used to declare namespaces, and should thus be handled similarly. This is the case for crpcut's TESTSUITE macro, or for unittest-cpp's SUITE macro: TESTSUITE(Foo) { TEST(MyFirstTest) { assert(0); } } // TESTSUITE(Foo) This patch deals with this cases by introducing a new option to specify lists of namespace macros. Internally, it re-uses the system already in place for foreach and statement macros, to ensure there is no impact on performance. Reviewers: krasimir, djasper, klimek Reviewed By: klimek Subscribers: acoomans, cfe-commits, klimek Tags: #clang Differential Revision: https://reviews.llvm.org/D37813 llvm-svn: 362740
* [clang-format] Allow configuring list of function-like macros that resolve ↵Francois Ferrand2019-05-291-7/+11
| | | | | | | | | | | | | | | | | | | | | | | to a type Summary: Adds a `TypenameMacros` configuration option that causes certain identifiers to be handled in a way similar to `typeof()`. This is enough to: - Prevent misinterpreting declarations of pointers to such types as expressions (`STACK_OF(int) * foo` -> `STACK_OF(int) *foo`), - Avoid surprising line breaks in variable/struct field declarations (`STACK_OF(int)\nfoo;` -> `STACK_OF(int) foo;`, see https://bugs.llvm.org/show_bug.cgi?id=30353). Reviewers: Typz, krasimir, djasper Reviewed By: Typz Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57184 llvm-svn: 361986
* Revert "Revert "[clang-format] Keep protobuf "package" statement on one line""Krasimir Georgiev2019-05-101-3/+3
| | | | | | | | | | | | | | | | | | | | | | | 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
* [clang-format] Use SpacesBeforeTrailingComments for "option" directiveKrasimir Georgiev2019-04-121-1/+4
| | | | | | | | | | | | | | | | | | | | | | 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
* [clang-format] Optionally insert a space after unary ! operatorReuben Thomas2019-04-081-1/+2
| | | | llvm-svn: 357908
* [clang-format] BreakAfterReturnType ignored on functions with numeric ↵Paul Hoad2019-04-061-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | template parameters Summary: Addresses PR40696 - https://bugs.llvm.org/show_bug.cgi?id=40696 The BreakAfterReturnType didn't work if it had a single arguments which was a template with an integer template parameter ``` int foo(A<8> a) { return a; } ``` When run with the Mozilla style. would not break after the `int` ``` int TestFn(A<8> a) { return a; } ``` This revision resolves this issue by allowing numeric constants to be considered function parameters if if seen inside `<>` Reviewers: djasper, klimek, JonasToth, krasimir, reuk, alexfh Reviewed By: klimek Subscribers: cfe-commits, llvm-commits Tags: #clang-tools-extra Differential Revision: https://reviews.llvm.org/D59309 llvm-svn: 357837
* [clang-format]: Add NonEmptyParentheses spacing optionReuben Thomas2019-03-301-4/+10
| | | | | | | | | | | | | This patch aims to add support for the following rules from the JUCE coding standards: - Always put a space before an open parenthesis that contains text - e.g. foo (123); - Never put a space before an empty pair of open/close parenthesis - e.g. foo(); Patch by Reuben Thomas Differential Revision: https://reviews.llvm.org/D55170 llvm-svn: 357344
* [clang-format] Add style option AllowShortLambdasOnASingleLineRonald Wampler2019-03-261-6/+19
| | | | | | | | | | | | | | | | | Summary: This option `AllowShortLambdasOnASingleLine` similar to the other `AllowShort*` options, but applied to C++ lambdas. Reviewers: djasper, klimek Reviewed By: klimek Subscribers: MyDeveloperDay, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57687 llvm-svn: 357027
* [clang-format] Refine structured binding detectionKrasimir Georgiev2019-03-251-8/+8
| | | | | | | | | | | | | | | | | | | | | Summary: Revision r356575 had the unfortunate consequence that now clang-format never detects an ObjC call expression after `&&`. This patch tries harder to distinguish between C++17 structured bindings and ObjC call expressions and adds a few regression tests. Reviewers: klimek Reviewed By: klimek Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59774 llvm-svn: 356928
* Revert "[clang-format] Keep protobuf "package" statement on one line"Haojian Wu2019-03-251-3/+3
| | | | | | | | | | | | | 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
* [clang-format] Keep protobuf "package" statement on one linePaul Hoad2019-03-231-3/+3
| | | | | | | | | | | | | | | | | | | | 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
* [clang-format] Add basic support for formatting C# filesPaul Hoad2019-03-211-1/+56
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This revision adds basic support for formatting C# files with clang-format, I know the barrier to entry is high here so I'm sending this revision in to test the water as to whether this might be something we'd consider landing. Tracking in Bugzilla as: https://bugs.llvm.org/show_bug.cgi?id=40850 Justification: C# code just looks ugly in comparison to the C++ code in our source tree which is clang-formatted. I've struggled with Visual Studio reformatting to get a clean and consistent style, I want to format our C# code on saving like I do now for C++ and i want it to have the same style as defined in our .clang-format file, so it consistent as it can be with C++. (Braces/Breaking/Spaces/Indent etc..) Using clang format without this patch leaves the code in a bad state, sometimes when the BreakStringLiterals is set, it fails to compile. Mostly the C# is similar to Java, except instead of JavaAnnotations I try to reuse the TT_AttributeSquare. Almost the most valuable portion is to have a new Language in order to partition the configuration for C# within a common .clang-format file, with the auto detection on the .cs extension. But there are other C# specific styles that could be added later if this is accepted. in particular how `{ set;get }` is formatted. Reviewers: djasper, klimek, krasimir, benhamilton, JonasToth Reviewed By: klimek Subscribers: llvm-commits, mgorny, jdoerfert, cfe-commits Tags: #clang, #clang-tools-extra Differential Revision: https://reviews.llvm.org/D58404 llvm-svn: 356662
* [clang-format] BeforeHash added to IndentPPDirectivesPaul Hoad2019-03-201-6/+9
| | | | | | | | | | | | | | | | | | Summary: The option BeforeHash added to IndentPPDirectives. Fixes Bug 36019. https://bugs.llvm.org/show_bug.cgi?id=36019 Reviewers: djasper, klimek, krasimir, sammccall, mprobst, Nicola, MyDeveloperDay Reviewed By: klimek, MyDeveloperDay Subscribers: kadircet, MyDeveloperDay, mnussbaum, geleji, ufna, cfe-commits Patch by to-mix. Differential Revision: https://reviews.llvm.org/D52150 llvm-svn: 356613
* [clang-format] structured binding in range for detected as Objective CPaul Hoad2019-03-201-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Sometime after 6.0.0 and the current trunk 9.0.0 the following code would be considered as objective C and not C++ Reported by: https://twitter.com/mattgodbolt/status/1096188576503644160 $ clang-format.exe test.h Configuration file(s) do(es) not support Objective-C: C:\clang\build\.clang-format --- test.h -- ``` std::vector<std::pair<std::string,std::string>> C; void foo() { for (auto && [A,B] : C) { std::string D = A + B; } } ``` The following code fixes this issue of incorrect detection Reviewers: djasper, klimek, JonasToth, reuk Reviewed By: klimek Subscribers: cfe-commits Tags: #clang-tools-extra Differential Revision: https://reviews.llvm.org/D59546 llvm-svn: 356575
* [clang-format] [JS] Don't break between template string and tagMartin Probst2019-03-191-0/+5
| | | | | | | | | | | | | | | | | | | Before: const x = veryLongIdentifier `hello`; After: const x = veryLongIdentifier`hello`; While it's allowed to have the template string and tag identifier separated by a line break, currently the clang-format output is not stable when a break is forced. Additionally, disallowing a line break makes it clear that the identifier is actually a tag for a template string. Patch originally by mitchellwills (thanks!). llvm-svn: 356447
* [clang-format] [NFC] clang-format the Format libraryPaul Hoad2019-03-011-13/+15
| | | | | | | | | | | Previously revisions commited non-clang-formatted changes to the Format library, this means submitting any revision e.g. {D55170} can cause additional whitespace changes to potentially be included in a revision. Commit a non functional change using latest build Windows clang-format r351376 with no other changes, to remove these differences All FormatTests pass [==========] 652 tests from 20 test cases ran. llvm-svn: 355182
* [clang-format] SpaceBeforeParens for lambda expressionsAndrew Ng2019-02-261-1/+3
| | | | | | | | | Add support for lambda expressions to the SpaceBeforeParens formatting option. Differential Revision: https://reviews.llvm.org/D58241 llvm-svn: 354880
* [Format/ObjC] Fix [foo bar]->baz formatting as lambda arrowBen Hamilton2019-02-081-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently, `UnwrappedLineParser` thinks an arrow token after an ObjC method expression is a C++ lambda arrow, so it formats: ``` [foo bar]->baz ``` as: ``` [foo bar] -> baz ``` Because `UnwrappedLineParser` runs before `TokenAnnotator`, it can't know if the arrow token is after an ObjC method expression or not. This diff makes `TokenAnnotator` remove the TT_LambdaArrow on the arrow token if it follows an ObjC method expression. Test Plan: New test added. Ran test with: % ninja FormatTests && ./tools/clang/unittests/Format/FormatTests Confirmed test failed before diff and passed after diff. Reviewers: krasimir, djasper, sammccall Reviewed By: sammccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57923 llvm-svn: 353531
* [clang-format] Fix breaking of qualified operatorKrasimir Georgiev2019-02-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: From https://bugs.llvm.org/show_bug.cgi?id=40516 ``` $ cat a.cpp const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::myFunction() { // do stuff } const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName::operator++() { // do stuff } $ ~/ll/build/opt/bin/clang-format -style=LLVM a.cpp const NamespaceName::VeryLongClassName & NamespaceName::VeryLongClassName::myFunction() { // do stuff } const NamespaceName::VeryLongClassName &NamespaceName::VeryLongClassName:: operator++() { // do stuff } ``` What was happening is that the split penalty before `operator` was being set to a smaller value by a prior if block. Moved checks around to fix this and added a regression test. Reviewers: djasper Reviewed By: djasper Tags: #clang Differential Revision: https://reviews.llvm.org/D57604 llvm-svn: 353033
* [clang-format] square parens with one token are not Objective-C message sendsAlex Lorenz2019-01-241-2/+7
| | | | | | | | | | | | | | The commit r322690 introduced support for ObjC detection in header files. Unfortunately some C headers that use designated initializers are now incorrectly detected as Objective-C. This commit fixes it by ensuring that `[ token ]` is not annotated as an Objective-C message send. rdar://45504376 Differential Revision: https://reviews.llvm.org/D56226 llvm-svn: 352125
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* clang-format: [JS] support goog.requireType.Martin Probst2019-01-071-0/+1
| | | | | | | | | | | | | | Summary: It's a new primitive for importing symbols, and should be treated like the (previously handled) `goog.require` and `goog.forwardDeclare`. Reviewers: krasimir Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D56385 llvm-svn: 350516
* [clang-format] Do not treat asm clobber [ as ObjCExpr, refinedKrasimir Georgiev2018-11-221-5/+6
| | | | | | | | | | | | | | | | | | | Summary: r346756 refined clang-format to not treat the `[` in `asm (...: [] ..)` as an ObjCExpr. However that's not enough, as we might have a comma-separated list of such clobbers as in the newly added test. This updates the detection to instead look at the Line's first token being `asm` and not mark `[`-s as ObjCExprs in this case. Reviewers: djasper, benhamilton Reviewed By: djasper, benhamilton Subscribers: benhamilton, cfe-commits Differential Revision: https://reviews.llvm.org/D54795 llvm-svn: 347465
* [clang-format] JS: don't treat is: as a type matcherKrasimir Georgiev2018-11-201-2/+15
| | | | | | | | | | | | | | | | Summary: Clang-format is treating all occurences of `is` in js as type matchers. In some cases this is wrong, as it might be a dict key. Reviewers: mprobst Reviewed By: mprobst Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D54753 llvm-svn: 347307
* [clang-format] Do not treat the asm clobber [ as ObjCExprKrasimir Georgiev2018-11-131-2/+3
| | | | | | | | | | | | | | | | | Summary: The opening square of an inline asm clobber was being annotated as an ObjCExpr. This caused, amongst other things, the ObjCGuesser to guess header files containing that pattern as ObjC files. Reviewers: benhamilton Reviewed By: benhamilton Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D54111 llvm-svn: 346756
* [clang-format] Support breaking consecutive string literals for TableGenJordan Rupprecht2018-11-121-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: clang-format can get confused by string literals in TableGen: it knows that strings can be broken up, but doesn't seem to understand how that can be indented across line breaks, and arranges them in a weird triangular pattern. Take this output example from `clang-format tools/llvm-objcopy/ObjcopyOpts.td` (which has now been formatted in rL345896 with this patch applied): ``` defm keep_global_symbols : Eq< "keep-global-symbols", "Reads a list of symbols from <filename> and " "runs as if " "--keep-global-symbol=<symbol> " "is set for each one. " "<filename> " "contains one " "symbol per line " "and may contain " "comments " "beginning " "with" " '#'" ". " "Lead" "ing " ``` Reviewers: alexshap, MaskRay, djasper Reviewed By: MaskRay Subscribers: krasimir, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D53952 llvm-svn: 346687
* Fix ClangFormat issue of recognizing ObjC subscript as C++ attributes when ↵Yan Zhang2018-11-091-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | message target is a result of a C-style method. Summary: The issue is that for array subscript like: ``` arr[[Foo() bar]]; ``` ClangFormat will recognize it as C++11 attribute syntax and put a space between 'arr' and first '[', like: ``` arr [[Foo() bar]]; ``` Now it is fixed. Tested with: ``` ninja FormatTests ``` Reviewers: benhamilton Reviewed By: benhamilton Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D54288 llvm-svn: 346566
* [clang-format] tweaked another case of lambda formattingKrasimir Georgiev2018-10-311-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is done in order to improve cases where the lambda's body is moved too far to the right. Consider the following snippet with column limit set to 79: ``` void f() { leader::MakeThisCallHere(&leader_service_, cq_.get(), [this, liveness](const leader::ReadRecordReq& req, std::function<void()> done) { logger_->HandleReadRecord( req, resp, std::move(done)); }); leader::MakeAnother(&leader_service_, cq_.get(), [this, liveness](const leader::ReadRecordReq& req, std::function<void()> done) { logger_->HandleReadRecord( req, resp, std::move(done), a); }); } ``` The tool favors extra indentation for the lambda body and so the code incurs extra wrapping and adjacent calls are indented to a different level. I find this behavior annoying and I'd like the tool to favor new lines and, thus, use the extra width. The fix, reduced, brings the following formatting. Before: function(1, [] { DoStuff(); // }, 1); After: function( 1, [] { DoStuff(); // }, 1); Refer to the new tests in FormatTest.cpp Contributed by oleg.smolsky! Reviewers: djasper, klimek, krasimir Subscribers: cfe-commits, owenpan Tags: #clang Differential Revision: https://reviews.llvm.org/D52676 llvm-svn: 345753
* clang-format: Don't insert spaces in front of :: for Java 8 Method References.Nico Weber2018-10-051-1/+7
| | | | | | | | | | | | | 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
* clang-format: [JS] conditional types.Martin Probst2018-09-271-0/+6
| | | | | | | | | | | | | | | | | | | | | Summary: This change adds some rudimentary support for conditional types. Specifically it avoids breaking before `extends` and `infer` keywords, which are subject to Automatic Semicolon Insertion, so breaking before them creates incorrect syntax. The actual formatting of the type expression is odd, but there is as of yet no clear idea on how to format these. See https://www.typescriptlang.org/docs/handbook/release-notes/typescript-2-8.html#conditional-types. Reviewers: krasimir Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D52536 llvm-svn: 343179
* clang-format: [JS] space after parameter naming.Martin Probst2018-09-261-1/+3
| | | | | | | | | | | | | | | | | | | Summary: Previously: foo(/*bar=*/baz); Now: foo(/*bar=*/ baz); The run-in parameter naming comment is not intended in JS. Reviewers: mboehme Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D52535 llvm-svn: 343080
* [clang-format/ObjC] Improve split priorities for ObjC methodsJacek Olesiak2018-07-091-2/+16
| | | | | | | | | | Reduce penalty for aligning ObjC method arguments using the colon alignment as this is the canonical way. Trying to fit a whole expression into one line should not force other line breaks (e.g. when ObjC method expression is a part of other expression). llvm-svn: 336520
* [clang-format/ObjC] Fix counting selector name parts for ObjCJacek Olesiak2018-07-091-11/+19
| | | | | | | | | | | | | | | | Summary: Counts selector parts also for method declarations and counts correctly for methods without arguments. This is an internal change and doesn't influence formatting on its own (at the current state). Its lack would be visible after applying D48719. Reviewers: benhamilton, klimek Reviewed By: benhamilton Subscribers: acoomans, cfe-commits Differential Revision: https://reviews.llvm.org/D48716 llvm-svn: 336518
* [clang-format/ObjC] Fix NS_SWIFT_NAME(foo(bar:baz:)) after ObjC method declBen Hamilton2018-06-291-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In D44638, I partially fixed `NS_SWIFT_NAME(foo(bar:baz:))`-style annotations on C functions, but didn't add a test for Objective-C method declarations. For ObjC method declarations which are annotated with `NS_SWIFT_NAME(...)`, we currently fail to annotate the final component of the selector name as `TT_SelectorName`. Because the token type is left unknown, clang-format will happily cause a compilation error when it changes the following: ``` @interface Foo - (void)doStuffWithFoo:(id)name bar:(id)bar baz:(id)baz NS_SWIFT_NAME(doStuff(withFoo:bar:baz:)); @end ``` to: ``` @interface Foo - (void)doStuffWithFoo:(id)name bar:(id)bar baz:(id)baz NS_SWIFT_NAME(doStuff(withFoo:bar:baz :)); @end ``` (note the linebreak before the final `:`). The logic which decides whether or not to annotate the token before a `:` with `TT_SelectorName` is pretty fragile, and has to handle some pretty odd cases like pair-parameters: ``` [I drawRectOn:surface ofSize:aa:bbb atOrigin:cc:dd]; ``` So, to minimize the effect of this change, I decided to only annotate unknown identifiers before a `:` as `TT_SelectorName` for Objective-C declaration lines. Test Plan: New tests included. Confirmed tests failed before change and passed after change. Ran tests with: % make -j16 FormatTests && ./tools/clang/unittests/Format/FormatTests Reviewers: djasper, krasimir, jolesiak Reviewed By: krasimir Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48679 llvm-svn: 335983
* [clang-format] Keep @message together in text protosKrasimir Georgiev2018-06-251-2/+19
| | | | | | | | | | | | Summary: In C++ code snippets of the form `@field` are common. This makes clang-format keep them together in text protos, whereas before it would break them. Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48543 llvm-svn: 335459
* [clang-format] Add SpaceBeforeCpp11BracedList option.Hans Wennborg2018-06-141-0/+3
| | | | | | | | | | | | | | | | | | | | WebKit C++ style for object initialization is as follows: Foo foo { bar }; Yet using clang-format -style=webkit changes this to: Foo foo{ bar }; As there is no existing combination of rules that will ensure a space before a braced list in this fashion, this patch adds a new SpaceBeforeCpp11BracedList rule. Patch by Ross Kirsling! Differential Revision: https://reviews.llvm.org/D46024 llvm-svn: 334692
* [clang-format] Discourage breaks in submessage entries, hard ruleKrasimir Georgiev2018-06-121-4/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* clang-format: [JS] strict prop init annotation.Martin Probst2018-06-111-1/+4
| | | | | | | | | | | | | | | | | | | | | | Summary: TypeScript uses the `!` token for strict property initialization assertions, as in: class X { strictPropAsserted!: string; } Previously, clang-format would wrap between the `!` and the `:` for overly long lines. This patch fixes that by generally preventing the wrap in that location. Reviewers: krasimir Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D48030 llvm-svn: 334415
* clang-format: Introduce BreakInheritanceList optionFrancois Ferrand2018-06-111-4/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This option replaces the BreakBeforeInheritanceComma option with an enum, thus introducing a mode where the colon stays on the same line as constructor declaration: // When it fits on line: class A : public B, public C { ... }; // When it does not fit: class A : public B, public C { ... }; This matches the behavior of the `BreakConstructorInitializers` option, introduced in https://reviews.llvm.org/D32479. Reviewers: djasper, klimek Reviewed By: djasper Subscribers: mzeren-vmw, cfe-commits Differential Revision: https://reviews.llvm.org/D43015 llvm-svn: 334408
* [clang-format] text protos: put entries on separate lines if there is a ↵Krasimir Georgiev2018-06-111-0/+68
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* clang-format: [JS] do not wrap before any `is`.Martin Probst2018-05-221-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: `is` type annotations can occur at any nesting level. For example: function x() { return function y(): a is B { ... }; } Breaking before the `is` above breaks TypeScript parsing the code. This change prevents the wrap. Reviewers: krasimir Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D47193 llvm-svn: 332968
OpenPOWER on IntegriCloud