djasper added a comment.
You are right that this behavior is what the code authors, but also many other
people, like to have and so it is what is engrained in clang-format. There are
likely about a million things that fall into the same category. Now we might
find that the current default is
Typz added a comment.
In https://reviews.llvm.org/D42787#1127790, @djasper wrote:
> The normal rule for formatting options apply. If you can dig up a public
> style guide and a project of reasonable size where it is used, we can add an
> option.
I don't want to be rude, but it seems to me
djasper added a comment.
The normal rule for formatting options apply. If you can dig up a public style
guide and a project of reasonable size where it is used, we can add an option.
Repository:
rC Clang
https://reviews.llvm.org/D42787
___
Typz added a comment.
Would it be acceptable to introduce an option to allow enabling this behavior?
I mean would it have a chance of being integrated, or must I keep maintaining a
fork of clang-format...
Repository:
rC Clang
https://reviews.llvm.org/D42787
chandlerc resigned from this revision.
chandlerc added a comment.
Since this seems not going anywhere, removing it from my review dashboard.
Repository:
rC Clang
https://reviews.llvm.org/D42787
___
cfe-commits mailing list
djasper added a comment.
We have talked about that and none of us agree.
Repository:
rC Clang
https://reviews.llvm.org/D42787
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Typz added a comment.
> Also double-checked with Richard Smith and he agrees that the current
> behavior is preferable. For comma and plus this doesn't seem overly
> important, but making it:
>
> aa(b + ccc *
> d);
>
>
> seems
djasper added a comment.
In https://reviews.llvm.org/D42787#1025117, @Typz wrote:
> If people don't care about this case, we might as well merge this :-) Just
> kidding.
>
> The tweak matches both our expectation, the auto-indent behaviour of IDE (not
> to be trusted, but still probably of
chandlerc added a comment.
In https://reviews.llvm.org/D42787#1000687, @krasimir wrote:
> We could adapt the single-argument version instead, turning:
>
> foo(bb +
> c);
>
>
> into:
>
> foo(bb +
> c);
>
I have
Typz added a comment.
If people don't care about this case, we might as well merge this :-) Just
kidding.
The tweak matches both our expectation, the auto-indent behaviour of IDE (not
to be trusted, but still probably of 'default' behaviour for many people, esp.
when you don't yet use a
djasper added a comment.
Are you sure that you are even addressing an important case? I have done some
research on our codebase and this is something that happens incredibly rarely.
The reason is that you have to have a very specific combination of line length,
where the last parameter does
Typz added a comment.
In https://reviews.llvm.org/D42787#1022081, @djasper wrote:
> But you *do* want extra indentation in the case of:
>
> function(a,
>b +
>cc);
>
>
> I understand you argument, but I don't agree at the moment. As is (without
> getting
djasper added a comment.
But you *do* want extra indentation in the case of:
function(a,
b +
cc);
I understand you argument, but I don't agree at the moment. As is (without
getting more feedback from others that clang-format is behaving unexpected
here), I
Typz added a comment.
In https://reviews.llvm.org/D42787#994781, @djasper wrote:
> What I mean is, users will find it surprising if whether or not a parameter
> gets wrapped leads to a different indentation internal to that parameter. I
> have not heard of a single user that would be surprised
Typz added a comment.
In https://reviews.llvm.org/D42787#1000687, @krasimir wrote:
> We could adapt the single-argument version instead, turning:
>
> foo(bb +
> c);
>
>
> into:
>
> foo(bb +
> c);
>
We could
krasimir added a comment.
We could adapt the single-argument version instead, turning:
foo(bb +
c);
into:
foo(bb +
c);
Repository:
rC Clang
https://reviews.llvm.org/D42787
djasper added a comment.
Ah, Manuel and Krasimir are already on this thread, maybe they can comment? I
also added Chandler and Sam who I know care about formatting somewhat.
Repository:
rC Clang
https://reviews.llvm.org/D42787
___
cfe-commits
djasper added a comment.
I don't mean trivial with a diff. What I mean is, users will find it surprising
if whether or not a parameter gets wrapped leads to a different indentation
internal to that parameter. I have not heard of a single user that would be
surprised by this extra indentation.
Typz added a comment.
> You might doubt it, but having written the code I can tell you that it's the
> case.
Ok, you win :-)
> I see the argument why this indentation is not necessary in exactly the case
> where the last parameter is multi-line and not wrapped to a new line itself:
> You
djasper added a comment.
You might doubt it, but having written the code I can tell you that it's the
case. Shame on me for not writing a test, though.
I see the argument why this indentation is not necessary in exactly the case
where the last parameter is multi-line and not wrapped to a new
Typz added a comment.
I doubt this particular was intentional, esp. since this case never happens in
the tests. I think it is more a side-effect of the (general) indent in "fake"
parenthesis.
Here is an exemple:
Before this change:
foo(a, bb +
djasper added a comment.
I am against this change. The current behavior here is intentional and IMO more
consistent. If there is more than one precedence level in a set of parentheses,
we add the additional indentation. If you don't like it, surround it with extra
parentheses.
Generally, it'd
Typz created this revision.
Typz added reviewers: krasimir, djasper, klimek.
There should be no extra indent when wrapping only the expression used
as last argument. This is consistent with the behavior when the first
(and only) argument's expression is wrapped.
foo(a, bb +
23 matches
Mail list logo
