This is an archive of the discontinued LLVM Phabricator instance.

clang-format properly handles try/catch blocks
ClosedPublic

Authored by sambatyon on Jan 15 2014, 8:22 AM.

Details

Reviewers
klimek
djasper
Summary

The patch adds a method so try/catch blocks are handled explicitly.

It generates the right formatting in all cases.

the generated output for Attach and Linux is now:

try {
    // something
} catch (...) {
    // something
}

for Stroustrup:

try {
    // something
}
catch (...) {
    // something
}

Allman:

try
{
    // something
}
catch (...)
{
    // something
}

And GNU:

try
    {
        // something
    }
catch (...)
    {
        // something
    }

Diff Detail

Event Timeline

sambatyon updated this revision to Unknown Object (????).Jan 15 2014, 8:55 AM

Just added the whole context

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...

lib/Format/UnwrappedLineParser.cpp
715

Perhaps: "We arrive here when parsing function-try blocks."

1042

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.

1043

Nit: add '.'.

1076

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...

Also please take a look at the comments I had on the original mail.

sambatyon added inline comments.Jan 22 2014, 5:31 AM
lib/Format/UnwrappedLineParser.cpp
1042

I've been thinking on how to parse the initializer list, and it might be quite cumbersome. I've been thinking on leaving out of this patch the ability of dealing with function-try blocks and leave it for latter (since I do this as a hobby, there's really a limit on how much time I can spend on this).

1043

Sorry, but what do you mean by “Nit”?

1075–1091

From Daniel: This needs a test case with multiple catch blocks.

1076

I don't get what you mean here. If the token is not tok::kw_catch, it won't start the while and NeedsUnwrappedLine will be true. Is there any other case that needs consideration?

klimek added inline comments.Jan 22 2014, 5:56 AM
lib/Format/UnwrappedLineParser.cpp
1042

I think we're misunderstanding each other here... What I mean is that we should parse *less* accurately. The thing to remember is that clang-format must work well on incorrect code. Thus, the structural parser tries hard to find only the structural elements that matter.

Regarding the time limits you have: especially when you do this as a hobby, I'd say this is the perfect venue to try to get things "right". As nobody forces you to do it, there's also no deadline pressure, so you can take all the time you need... The worst that can happen is that somebody asks you whether they can take over and finish the patch if they need it more urgently.

1043

A minor comment that's not really important :)

1076

Well, what do we do on this snippet:

...
} catch (Type) ANNOTATION_MACRO(something else) {
   ...
}

As I said, I'm not sure exactly how to resolve this.

Daniel, do you have ideas here?

djasper added inline comments.Jan 22 2014, 6:11 AM
lib/Format/UnwrappedLineParser.cpp
1076

Maybe we should just consume everything until the next "{" (possibly recognizing a few error cases explicitly - e.g. ";" or "}").

Hi. Are you moving forward with this? Somebody else has also started a similar patch: http://llvm-reviews.chandlerc.com/D2731.

sdt added inline comments.Feb 10 2014, 3:24 PM
lib/Format/UnwrappedLineParser.cpp
1042

I don't think you can just consume until the next brace, due to brace initialization:

try : foo{}, bar{nullptr} {} catch (...) {}
sdt added inline comments.Feb 11 2014, 1:09 PM
lib/Format/UnwrappedLineParser.cpp
1042

klimek, when you say that you'd like to have parseInitializerList() broken out, do you mean for it to be used anywhere else, or just to pull it out to make it cleaner here and in potential future uses? I couldn't find anywhere we explicitly parse initializer lists already.

sambatyon added inline comments.Feb 20 2014, 9:21 AM
lib/Format/UnwrappedLineParser.cpp
1042

I actually had an implementation of that and then while writing a test I realized that didn't work. The best option is to actually parse the initializer list.

I think I will let sdt take care of this.

djasper accepted this revision.May 8 2014, 5:06 AM
djasper edited edge metadata.

I addressed the comments, added tests and submitted this as r208302. Thank you!

This revision is now accepted and ready to land.May 8 2014, 5:06 AM
djasper closed this revision.May 8 2014, 5:06 AM