[PATCH] clang-format properly handles try/catch blocks

Manuel Klimek klimek at google.com
Wed Jan 15 09:24:27 PST 2014


  Overall, I'm not sure whether we can basically just parse:
  try ... {<block>} catch ... {<block} ...
  where we just eat away anything between the try/catch and the opening brace...


================
Comment at: lib/Format/UnwrappedLineParser.cpp:715
@@ +714,3 @@
+    case tok::kw_try:
+      // It enters here in function-try blocks
+      parseTryCatch();
----------------
Perhaps: "We arrive here when parsing function-try blocks."

================
Comment at: lib/Format/UnwrappedLineParser.cpp:1043
@@ +1042,3 @@
+  if (FormatTok->Tok.is(tok::colon)) {
+      // We are in a function try block, what comes is an initializer list
+      nextToken();
----------------
Nit: add '.'.

================
Comment at: lib/Format/UnwrappedLineParser.cpp:1042
@@ +1041,3 @@
+  bool NeedsUnwrappedLine = false;
+  if (FormatTok->Tok.is(tok::colon)) {
+      // We are in a function try block, what comes is an initializer list
----------------
I'm wondering whether we just want to eat everything up to the next '{'. In general, we try to parse as little as possible in the structural parser.

If we decide we really need to parse the structure here, I think we should pull out a parseInitializerList() method.

================
Comment at: lib/Format/UnwrappedLineParser.cpp:1076
@@ +1075,3 @@
+  while (FormatTok->Tok.is(tok::kw_catch)) {
+    nextToken();
+    if (FormatTok->Tok.is(tok::l_paren))
----------------
Same here. The problem is if anybody ever finds a real use case to put anything in between (including macros) we might fail to parse the file...


http://llvm-reviews.chandlerc.com/D2555



More information about the cfe-commits mailing list