summaryrefslogtreecommitdiffstats
path: root/clang/lib/Format/FormatTokenLexer.cpp
Commit message (Collapse)AuthorAgeFilesLines
* clang-format: [JS] support null operators.Martin Probst2019-11-111-0/+12
| | | | | | | | | | | | | | | | | | | Summary: JavaScript / TypeScript is adding two new operators: the null propagating operator `?.` and the nullish coalescing operator `??`. const x = foo ?? 'default'; const z = foo?.bar?.baz; This change adds support to lex and format both. Reviewers: krasimir Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69971
* [clang-format] [PR43338] C# clang format has space issues betweern C# only ↵Paul Hoad2019-10-041-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | keywords Summary: When formatting C# there can be issues with a lack of spaces between `using (` , `foreach (` and generic types The C# code ``` public class Foo { Dictionary<string,string> foo; } ``` will be formatted as ``` public class Foo { Dictionary<string, string>foo; ^^^^^ missing a space } ``` This revision also reverts some of {D66662} in order to make this cleaner and resolve an issues seen by @owenpan that the formatting didn't add a space when not in a code block This also transforms C# foreach commands to be seen as tok::kw_for commands (to ensure foreach gets the same Brace Wrapping behavior as for without littering the code with `if(Style.isCSharp())` Reviewers: owenpan, klimek, russellmcc, mitchell-stellar Reviewed By: mitchell-stellar Subscribers: cfe-commits Tags: #clang, #clang-format Differential Revision: https://reviews.llvm.org/D67660 llvm-svn: 373709
* [clang-format][PR41964] Fix crash with SIGFPE when TabWidth is set to 0 and ↵Paul Hoad2019-09-181-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | line starts with tab Summary: clang-format 8.0 crashes with SIGFPE (floating point exception) when formatting following file: app.cpp: void a() { //line starts with '\t' } $ clang-format -style='{TabWidth: 0}' app.cpp Reviewers: owenpan, klimek, russellmcc, timwoj Reviewed By: klimek Subscribers: cfe-commits Tags: #clang-tools-extra, #clang Differential Revision: https://reviews.llvm.org/D67670 llvm-svn: 372246
* clang-format: better handle namespace macrosFrancois Ferrand2019-06-061-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-0/+2
| | | | | | | | | | | | | | | | | | | | | | | 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
* [clang-format] Fixed self assignmentDavid Bolvansky2019-05-151-1/+0
| | | | | | | | | | | | | | Reviewers: MyDeveloperDay, RKSimon Reviewed By: MyDeveloperDay Subscribers: RKSimon, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61281 llvm-svn: 360810
* [clang-format] Add basic support for formatting C# filesPaul Hoad2019-03-211-0/+109
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] [JS] handle private members.Martin Probst2019-03-191-0/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Addresses PR40999 https://bugs.llvm.org/show_bug.cgi?id=40999 Private fields and methods in JavaScript would get incorrectly indented (it sees them as preprocessor directives and hence left aligns them) In this revision `#identifier` tokens `tok::hash->tok::identifier` are merged into a single new token `tok::identifier` with the `#` contained inside the TokenText. Before: ``` class Example { pub = 1; static pub2 = "foo"; static #priv2 = "bar"; method() { this.#priv = 5; } static staticMethod() { switch (this.#priv) { case '1': break; } } this.#privateMethod(); // infinite loop } static #staticPrivateMethod() {} } ``` After this fix the code will be correctly indented ``` class Example { pub = 1; #priv = 2; static pub2 = "foo"; static #priv2 = "bar"; method() { this.#priv = 5; } static staticMethod() { switch (this.#priv) { case '1': #priv = 3; break; } } #privateMethod() { this.#privateMethod(); // infinite loop } static #staticPrivateMethod() {} } ``` NOTE: There might be some JavaScript code out there which uses the C processor to preprocess .js files http://www.nongnu.org/espresso/js-cpp.html. It's not clear how this revision or even private fields and methods would interact. Patch originally by MyDeveloperDays (thanks!). llvm-svn: 356449
* 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: better handle statement macrosFrancois Ferrand2018-10-021-5/+6
| | | | | | | | | | | | | | | | | | | | | | Summary: Some macros are used in the body of function, and actually contain the trailing semicolon: they should thus be automatically followed by a new line, and not get merged with the next line. This is for example the case with Qt's Q_UNUSED macro: void foo(int a, int b) { Q_UNUSED(a) return b; } This patch deals with these cases by introducing a new option to specify list of statement macros. This re-uses the system already in place for foreach macros, to ensure there is no impact on performance. Reviewers: krasimir, djasper, klimek Reviewed By: krasimir Subscribers: acoomans, mgrang, alexfh, klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D33440 llvm-svn: 343602
* llvm::sort(C.begin(), C.end(), ...) -> llvm::sort(C, ...)Fangrui Song2018-09-261-1/+1
| | | | | | | | | | | | | | Summary: The convenience wrapper in STLExtras is available since rL342102. Reviewers: rsmith, #clang, dblaikie Reviewed By: rsmith, #clang Subscribers: mgrang, arphaman, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D52576 llvm-svn: 343147
* [clang-format] Consider tok::hashhash in python-style commentsKrasimir Georgiev2018-06-071-1/+1
| | | | | | | | | | Summary: We were missing the case when python-style comments in text protos start with `##`. Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47870 llvm-svn: 334179
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-1/+1
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* [clang] Change std::sort to llvm::sort in response to r327219Mandeep Singh Grang2018-03-271-1/+1
| | | | | | | | | | | r327219 added wrappers to std::sort which randomly shuffle the container before sorting. This will help in uncovering non-determinism caused due to undefined sorting order of objects having the same key. To make use of that infrastructure we need to invoke llvm::sort instead of std::sort. llvm-svn: 328636
* clang-format: Properly handle implicit string concatenation in text protosDaniel Jasper2018-03-121-1/+3
| | | | | | | | | | | | | Three issues to fix: - char_constants weren't properly treated as string literals - Prevening the break after "label: " does not make sense in concunction with AlwaysBreakBeforeMultilineStrings. It leads to situations where clang-format just cannot find a viable format (it must break and yet it must not break). - AlwaysBreakBeforeMultilineStrings should not be on for LK_TextProto in Google style. llvm-svn: 327255
* [clang-format] Support python-style comments in text protosKrasimir Georgiev2017-11-101-0/+23
| | | | | | | | | | | | | | Summary: This patch adds support for python-style comments in text protos. Reviewers: djasper Reviewed By: djasper Subscribers: bkramer, cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D39806 llvm-svn: 317886
* [clang-format] Handle CRLF correctly when formatting escaped newlinesKrasimir Georgiev2017-10-301-5/+13
| | | | | | | | | | Subscribers: klimek Differential Revision: https://reviews.llvm.org/D39420 Contributed by @peterbudai! llvm-svn: 316910
* [clang-format] Format raw string literalsKrasimir Georgiev2017-10-301-2/+2
| | | | | | | | | | | | | | | 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/java: Unbreak genenrics formatting after r299952.Nico Weber2017-09-271-4/+0
| | | | | | | | | | | | | | 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
* clang-format clang-format.Manuel Klimek2017-09-201-9/+6
| | | | llvm-svn: 313744
* clang-format: [JS] handle single lines comments ending in `\\`.Martin Probst2017-08-081-0/+28
| | | | | | | | | | | | | | Summary: Previously, clang-format would consider the following code line to be part of the comment and incorrectly format the rest of the file. Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D36159 llvm-svn: 310365
* clang-format: [JS] exponentiation operatorMartin Probst2017-05-041-0/+10
| | | | | | | | | | | | Summary: While its precedence should be higher than multiplicative, LLVM does not have a level for that, so for the time being just treat it as multiplicative. Reviewers: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D32864 llvm-svn: 302156
* Fix mishandling of escaped newlines followed by newlines or nuls.Richard Smith2017-04-171-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, if an escaped newline was followed by a newline or a nul, we'd lex the escaped newline as a bogus space character. This led to a bunch of different broken corner cases: For the pattern "\\\n\0#", we would then have a (horizontal) space whose spelling ends in a newline, and would decide that the '#' is at the start of a line, and incorrectly start preprocessing a directive in the middle of a logical source line. If we were already in the middle of a directive, this would result in our attempting to process multiple directives at the same time! This resulted in crashes, asserts, and hangs on invalid input, as discovered by fuzz-testing. For the pattern "\\\n" at EOF (with an implicit following nul byte), we would produce a bogus trailing space character with spelling "\\\n". This was mostly harmless, but would lead to clang-format getting confused and misformatting in rare cases. We now produce a trailing EOF token with spelling "\\\n", consistent with our handling for other similar cases -- an escaped newline is always part of the token containing the next character, if any. For the pattern "\\\n\n", this was somewhat more benign, but would produce an extraneous whitespace token to clients who care about preserving whitespace. However, it turns out that our lexing for line comments was relying on this bug due to an off-by-one error in its computation of the end of the comment, on the slow path where the comment might contain escaped newlines. llvm-svn: 300515
* [clang-format] Recognize Java logical shift assignment operator Nico Weber2017-04-111-0/+13
| | | | | | | | | | | | | | | | | | | | | | 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
* [clang-format] Handle NSString literals by merging tokens.Alexander Kornienko2017-04-111-0/+18
| | | | | | | | | | | | | | | | | | | | Summary: This fixes a few outstanding bugs: * incorrect breaking of NSString literals containing double-width characters; * inconsistent formatting of ObjC dictionary literals containing NSString literals; * AlwaysBreakBeforeMultilineStrings ignoring implicitly-concatenated NSString literals. Reviewers: djasper Reviewed By: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D31706 llvm-svn: 299927
* clang-format: Fix post-commit review comment of r299204, use Style.isCpp().Daniel Jasper2017-03-311-1/+1
| | | | | | Also, while at it, s/IsCpp/isCpp/ so that it follows LLVM style. llvm-svn: 299214
* clang-format: Fix many Objective-C formatting regressions from r289428Nico Weber2017-02-241-2/+1
| | | | | | | | | | | | | | | 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: [JS] exclaim preceding regex literals.Martin Probst2017-02-071-1/+3
| | | | | | | | | | | | | | | | | | | | Summary: Regex detection would incorrectly classify a trailing `!` operator (nullability cast) followed by a `/` as the start of a regular expression literal. This fixes code such as: var foo = x()! / 10; Which would previously parse a regexp all the way to the end of the source file (or next `/`). Reviewers: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D29634 llvm-svn: 294304
* clang-format: Separate out a language kind for ObjC.Daniel Jasper2016-12-121-1/+2
| | | | | | | | | | | | | While C(++) and ObjC are generally formatted the same way and can be mixed, people might want to choose different styles based on the language. This patch recognizes .m and .mm files as ObjC and also implements a very crude detection of whether or not a .h file contains ObjC code. This can be improved over time. Also move most of the ObjC tests into their own test file to keep file size maintainable. llvm-svn: 289428
* Fixed column shift when formatting line containing bit shift operatorsMalcolm Parsons2016-11-031-0/+2
| | | | | | | | | | | | | | | | | | | Summary: During clang-format source lexing >> and << operators are split and treated as two less/greater operators but column position of following tokens was not adjusted accordingly. Fixes PR26887 Patch by Paweł Żukowski. Reviewers: djasper Subscribers: malcolm.parsons, mprobst, klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D25439 llvm-svn: 285934
* clang-format: [JS] Fix a crash in handledTemplateStrings.Daniel Jasper2016-09-171-0/+2
| | | | llvm-svn: 281816
* clang-format: [JS] nested and tagged template strings.Martin Probst2016-08-251-20/+43
| | | | | | | | | | | | | | | | | | | JavaScript template strings can be nested arbitrarily: foo = `text ${es.map(e => { return `<${e}>`; })} text`; This change lexes nested template strings using a stack of lexer states to correctly switch back to template string lexing on closing braces. Also, reuse the same stack for the token-stashed logic. Reviewers: djasper Subscribers: cfe-commits, klimek Differential Revision: https://reviews.llvm.org/D22431 llvm-svn: 279727
* clang-format: [JS] sort ES6 imports.Martin Probst2016-05-201-0/+597
Summary: This change automatically sorts ES6 imports and exports into four groups: absolute imports, parent imports, relative imports, and then exports. Exports are sorted in the same order, but not grouped further. To keep JS import sorting out of Format.cpp, this required extracting the TokenAnalyzer infrastructure to separate header and implementation files. Reviewers: djasper Subscribers: cfe-commits, klimek Differential Revision: http://reviews.llvm.org/D20198 llvm-svn: 270203
OpenPOWER on IntegriCloud