[PATCH] clang-format: [JS] Better support for fat arrows.

[Martin Probst]

PTAL.


================
Comment at: lib/Format/UnwrappedLineParser.cpp:885-887
@@ -884,1 +884,5 @@
     case tok::equal:
+      // Fat arrows (=>) have TokenKind tok::equal. The always start an
+      // expression or a child block if followed by a curly.
+      if (FormatTok->is(TT_JsFatArrow)) {
+        nextToken();
----------------
klimek wrote:
> Seems like they have TokenKind TT_JsFatArrow now.
It has TokenType TT_JsFatArrow, but tok::TokenKind tok::equal. Don't blame me, I'm just the messenger :-)

Updated the comment to be explicit about tok::TokenKind.

================
Comment at: lib/Format/UnwrappedLineParser.cpp:1044-1045
@@ -1020,1 +1043,4 @@
 
+void UnwrappedLineParser::parseBalanced(tok::TokenKind OpenKind,
+                                        tok::TokenKind CloseKind) {
+  int Depth = 1;
----------------
klimek wrote:
> Most of the time we enter parse* functions with the first token of that projection. In this case, I'd expect the current token still be the OpenKind.
Done, that's better indeed.

================
Comment at: lib/Format/UnwrappedLineParser.cpp:1048
@@ +1047,3 @@
+  while (Depth > 0 && !eof()) {
+    // Parse the formal parameter list
+    if (FormatTok->is(OpenKind)) {
----------------
klimek wrote:
> Nit: add '.'
Done.

================
Comment at: lib/Format/UnwrappedLineParser.cpp:1050
@@ +1049,3 @@
+    if (FormatTok->is(OpenKind)) {
+      Depth++;
+    } else if (FormatTok->is(CloseKind)) {
----------------
klimek wrote:
> Use pre-increment in C++.
Done.

================
Comment at: lib/Format/UnwrappedLineParser.h:110-114
@@ -109,2 +109,7 @@
   void tryToParseJSFunction();
+  // Parses tokens until encountering the CloseKind token, but balances tokens
+  // when encountering more OpenKind tokens. Useful for e.g. parsing a curly
+  // brace delimited block that can contain nested blocks.
+  // The parser must be positioned just past a token of OpenKind.
+  void parseBalanced(tok::TokenKind OpenKind, tok::TokenKind CloseKind);
   void addUnwrappedLine();
----------------
klimek wrote:
> a) use doxygen comments for functions
> b) we usually don't have nested parens or nested blocks where there can't be anything in we'd want to parse explicitly; I assume you know what you're doing for JS here, but I find that really curious
(a): done.
(b): this matches what the code used to do before. In the positions where I call it, there can never be stuff that belongs on separate lines (it's within a formal parameter list or within inline type declarations). I'm not 100% certain this will always be the best thing to do, but it's definitely not a regression and I cannot come up with a case where it'd be wrong right now.

http://reviews.llvm.org/D9906

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/