r199198 - clang-format: Fix bug introduced in r198871.

[Jordan Rose]

That's true; none of the other literals will be split (except the @() one, which behaves like any other parenthetical). I was just trying to back-explain why it's nicer for the Parser and AST to not put the @ into the string literal token.

Jordan


On Jan 14, 2014, at 11:13, Daniel Jasper <djasper at google.com> wrote:

> Yeah.. I think that works fine. The crucial problem here is the case where clang-format needs to split the string-literal and add additional '@'s.. I don't think that applies to other literals. Or are you thinking of something specific?
> 
> 
> On Tue, Jan 14, 2014 at 6:04 PM, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> On Jan 14, 2014, at 1:53 , Daniel Jasper <djasper at google.com> wrote:
> 
> > Author: djasper
> > Date: Tue Jan 14 03:53:07 2014
> > New Revision: 199198
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=199198&view=rev
> > Log:
> > clang-format: Fix bug introduced in r198871.
> >
> > We cannot simply change the start column to accomodate for the @ in an
> > ObjC string literal as that will make clang-format happily violate the
> > column limit.
> >
> > Use a different workaround instead. However, a better long-term
> > solution might be to join the @ and the rest of the literal into a
> > single token.
> 
> Eh, you're going to have this problem with every other @ literal now: @123, @YES (expands to @__objc_yes), @(cos(x)). It pretty much always wants to stick to its following token, whatever that may be.
> 
> Jordan
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20140114/83f11211/attachment.html>