diff options
author | Martin Probst <martin@probst.io> | 2017-05-31 09:29:40 +0000 |
---|---|---|
committer | Martin Probst <martin@probst.io> | 2017-05-31 09:29:40 +0000 |
commit | 95ed8e7928b8d03a6289ac128ca4151ba3127d8d (patch) | |
tree | 121623a507166f8b9eccdff7e57e286134e121f3 /clang/lib/Format/UnwrappedLineParser.cpp | |
parent | ea79b215d68b46809d82f5a5a87028d1e5c47140 (diff) | |
download | bcm5719-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.cpp | 25 |
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, |