On Thu, Nov 21, 2013 at 3:56 PM, Daniel Jasper <[email protected]> wrote:
> I don't feel strongly about this. However, putting then decision into > mustBreak would just work. You don't need any special casing for the > single-line case as that is handled by a different code path.. > You mean putting all the tryMerge.* methods to mustBreak? > On Nov 21, 2013 2:22 AM, "Alexander Kornienko" <[email protected]> wrote: > >> Having played with this a bit, I found a few problems with not putting >> the braces into separate lines in the UnwrappedLinesParser: >> * if we have braces on the same unwrapped line, we'll need to introduce >> a break when laying them out (using TokenAnnotator::mustBreak), and we'll >> have to undo this break when joining lines (IIUC, line joiner currently >> doesn't support this); >> * when MustBreakBefore is set, we also make TotalLength > ColumnLimit, >> and we'll need to undo this in line joiner, which will also add complexity. >> >> Overall, always having the braces on the same unwrapped line doesn't seem >> to be able to simplify the code =\ >> >> >> On Wed, Nov 20, 2013 at 7:32 PM, Daniel Jasper <[email protected]>wrote: >> >>> >>> On Wed, Nov 20, 2013 at 9:28 AM, Alexander Kornienko >>> <[email protected]>wrote: >>> >>>> On Wed, Nov 20, 2013 at 6:12 PM, Daniel Jasper <[email protected]>wrote: >>>> >>>>> >>>>>> @@ -681,6 +681,7 @@ void UnwrappedLineParser::parseStructura >>>>>> Style.BreakBeforeBraces == FormatStyle::BS_Stroustrup || >>>>>> Style.BreakBeforeBraces == FormatStyle::BS_Allman) >>>>>> addUnwrappedLine(); >>>>>> >>>>> >>>>> Does it still make sense to report the "{" as its own unwrapped line? >>>>> Seems a bit convoluted to first report multiple lines and then merge them >>>>> afterwards. I think this would make the merging code simpler. >>>>> >>>> >>>> It also seemed strange to me. Should we instead handle >>>> BreakBeforeBraces in TokenAnnotator? This will require adding TokenType >>>> values for braces starting namespaces, classes/structs and, probably, >>>> enums. I can play with this a bit, it you think it makes sense. >>>> >>> >>> I might have already done this for enums. I don't think it is essential >>> to add token types for all of these as e.g. enums and namespaces are really >>> easy to detect. But adding token types might be the cleaner solution. I >>> think that this makes sense but I remember having some kind of debate over >>> this with Manuel, so he might have an opinion. >>> >>
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
