r195256 - Added an option to allow short function bodies be placed on a single line.

[Daniel Jasper]

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..
On Nov 21, 2013 2:22 AM, "Alexander Kornienko" <alexfh at google.com> 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 <djasper at google.com> wrote:
>
>>
>> On Wed, Nov 20, 2013 at 9:28 AM, Alexander Kornienko <alexfh at google.com>wrote:
>>
>>> On Wed, Nov 20, 2013 at 6:12 PM, Daniel Jasper <djasper at google.com>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.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131121/54f386ef/attachment.html>