summaryrefslogtreecommitdiffstats
path: root/clang/lib/Format/UnwrappedLineParser.cpp
diff options
context:
space:
mode:
authorMartin Probst <martin@probst.io>2017-05-31 09:29:40 +0000
committerMartin Probst <martin@probst.io>2017-05-31 09:29:40 +0000
commit95ed8e7928b8d03a6289ac128ca4151ba3127d8d (patch)
tree121623a507166f8b9eccdff7e57e286134e121f3 /clang/lib/Format/UnwrappedLineParser.cpp
parentea79b215d68b46809d82f5a5a87028d1e5c47140 (diff)
downloadbcm5719-llvm-95ed8e7928b8d03a6289ac128ca4151ba3127d8d.tar.gz
bcm5719-llvm-95ed8e7928b8d03a6289ac128ca4151ba3127d8d.zip
clang-format: [JS] improve calculateBraceType heuristic
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
Diffstat (limited to 'clang/lib/Format/UnwrappedLineParser.cpp')
-rw-r--r--clang/lib/Format/UnwrappedLineParser.cpp25
1 files changed, 16 insertions, 9 deletions
diff --git a/clang/lib/Format/UnwrappedLineParser.cpp b/clang/lib/Format/UnwrappedLineParser.cpp
index ae79ea5d8a6..eda7ef36434 100644
--- a/clang/lib/Format/UnwrappedLineParser.cpp
+++ b/clang/lib/Format/UnwrappedLineParser.cpp
@@ -360,16 +360,21 @@ void UnwrappedLineParser::calculateBraceTypes(bool ExpectClassBody) {
switch (Tok->Tok.getKind()) {
case tok::l_brace:
- if (Style.Language == FormatStyle::LK_JavaScript && PrevTok &&
- PrevTok->is(tok::colon))
- // A colon indicates this code is in a type, or a braced list following
- // a label in an object literal ({a: {b: 1}}).
- // The code below could be confused by semicolons between the individual
- // members in a type member list, which would normally trigger BK_Block.
- // In both cases, this must be parsed as an inline braced init.
- Tok->BlockKind = BK_BracedInit;
- else
+ if (Style.Language == FormatStyle::LK_JavaScript && PrevTok) {
+ if (PrevTok->is(tok::colon))
+ // A colon indicates this code is in a type, or a braced list
+ // following a label in an object literal ({a: {b: 1}}). The code
+ // below could be confused by semicolons between the individual
+ // members in a type member list, which would normally trigger
+ // BK_Block. In both cases, this must be parsed as an inline braced
+ // init.
+ Tok->BlockKind = BK_BracedInit;
+ else if (PrevTok->is(tok::r_paren))
+ // `) { }` can only occur in function or method declarations in JS.
+ Tok->BlockKind = BK_Block;
+ } else {
Tok->BlockKind = BK_Unknown;
+ }
LBraceStack.push_back(Tok);
break;
case tok::r_brace:
@@ -391,6 +396,8 @@ void UnwrappedLineParser::calculateBraceTypes(bool ExpectClassBody) {
// BlockKind later if we parse a braced list (where all blocks
// inside are by default braced lists), or when we explicitly detect
// blocks (for example while parsing lambdas).
+ // FIXME: Some of these do not apply to JS, e.g. "} {" can never be a
+ // braced list in JS.
ProbablyBracedList =
(Style.Language == FormatStyle::LK_JavaScript &&
NextTok->isOneOf(Keywords.kw_of, Keywords.kw_in,
OpenPOWER on IntegriCloud