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

Manuel Klimek klimek at google.com
Wed Feb 12 00:51:48 PST 2014


On Tue, Feb 11, 2014 at 10:09 PM, Stefanus Du Toit <
stefanus.du.toit at intel.com> wrote:

>
>
> ================
> 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
> ----------------
> Stefanus Du Toit wrote:
> > Manuel Klimek wrote:
> > > Alexander Rojas wrote:
> > > > Manuel Klimek wrote:
> > > > > 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.
> > > > 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).
> > > 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.
> > I don't think you can just consume until the next brace, due to brace
> initialization:
> >
> >   try : foo{}, bar{nullptr} {} catch (...) {}
> >
> 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.
>

I think the code is easier to understand when factored there, that's all :)

Cheers,
/Manuel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140212/c0bee880/attachment.html>


More information about the cfe-commits mailing list