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
_______________________________________________
cfe-commits mailing list
[email protected]
http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
