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 <[email protected]> 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 <[email protected]> wrote: > > On Jan 14, 2014, at 1:53 , Daniel Jasper <[email protected]> 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 >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
