[PATCH RESEND] clang-format: Set IndentWrappedFunctionNames false

[PATCH RESEND] clang-format: Set IndentWrappedFunctionNames false

[Jason Gunthorpe]

The true option causes this indenting for functions:

static struct something_very_very_long *
    function(void *arg)
{

While a quick survey suggests that the usual Linux fallback is the GNU
style:

static struct something_very_very_long *
function(void *arg)
{

Eg as seen in:

kernel/cpu.c
kernel/fork.c
etc

Acked-by: Joe Perches <joe@perches.com>
Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
---
 .clang-format | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Resending outside the merge window with no change..

If there is no clear upstream path for this file (it has no
MAINTAINERS entry?) I could take it to Linus via the rdma.git tree, eg
as a 'collectively maintained' file.

Would prefer Miguel's Ack to do that though. Looks like Andrew Morton
took the original patch introducing the file?

Thanks,
Jason

diff --git a/.clang-format b/.clang-format
index faffc0d5af4eeb..1d5da22e0ba50c 100644
--- a/.clang-format
+++ b/.clang-format
@@ -382,7 +382,7 @@ IncludeIsMainRegex: '(Test)?$'
 IndentCaseLabels: false
 #IndentPPDirectives: None # Unknown to clang-format-5.0
 IndentWidth: 8
-IndentWrappedFunctionNames: true
+IndentWrappedFunctionNames: false
 JavaScriptQuotes: Leave
 JavaScriptWrapImports: true
 KeepEmptyLinesAtTheStartOfBlocks: false
-- 
2.17.0

Re: [PATCH RESEND] clang-format: Set IndentWrappedFunctionNames false

[Miguel Ojeda]

Hi,

On Tue, Jun 26, 2018 at 12:44 AM, Jason Gunthorpe <jgg@mellanox.com> wrote:
> The true option causes this indenting for functions:
>
> static struct something_very_very_long *
>     function(void *arg)
> {
>
> While a quick survey suggests that the usual Linux fallback is the GNU
> style:
>
> static struct something_very_very_long *
> function(void *arg)
> {
>
> Eg as seen in:
>
> kernel/cpu.c
> kernel/fork.c
> etc
>
> Acked-by: Joe Perches <joe@perches.com>
> Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
> ---
>  .clang-format | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> Resending outside the merge window with no change..
>
> If there is no clear upstream path for this file (it has no
> MAINTAINERS entry?) I could take it to Linus via the rdma.git tree, eg

We can add an specific entry, yeah. Is there any policy for "general
files" (or some general/catch-all entry)?

> as a 'collectively maintained' file.

As you prefer -- I can also pick it up through auxdisplay; but I am
not sure if we should put it in any "unrelated" tree, though. (Since
the file will not probably receive many patches, I originally thought
that it would be picked up by Andrew or some other "general" tree
instead.)

>
> Would prefer Miguel's Ack to do that though. Looks like Andrew Morton
> took the original patch introducing the file?

Yep, I sent it to Andrew and he kindly picked it up. Probably he
didn't notice this one.

As for the patch:

Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>

Cheers,
Miguel

>
> Thanks,
> Jason
>
> diff --git a/.clang-format b/.clang-format
> index faffc0d5af4eeb..1d5da22e0ba50c 100644
> --- a/.clang-format
> +++ b/.clang-format
> @@ -382,7 +382,7 @@ IncludeIsMainRegex: '(Test)?$'
>  IndentCaseLabels: false
>  #IndentPPDirectives: None # Unknown to clang-format-5.0
>  IndentWidth: 8
> -IndentWrappedFunctionNames: true
> +IndentWrappedFunctionNames: false
>  JavaScriptQuotes: Leave
>  JavaScriptWrapImports: true
>  KeepEmptyLinesAtTheStartOfBlocks: false
> --
> 2.17.0
>

Re: [PATCH RESEND] clang-format: Set IndentWrappedFunctionNames false

[Jason Gunthorpe]

On Tue, Jun 26, 2018 at 05:05:40PM +0200, Miguel Ojeda wrote:
> Hi,
> 
> On Tue, Jun 26, 2018 at 12:44 AM, Jason Gunthorpe <jgg@mellanox.com> wrote:
> > The true option causes this indenting for functions:
> >
> > static struct something_very_very_long *
> >     function(void *arg)
> > {
> >
> > While a quick survey suggests that the usual Linux fallback is the GNU
> > style:
> >
> > static struct something_very_very_long *
> > function(void *arg)
> > {
> >
> > Eg as seen in:
> >
> > kernel/cpu.c
> > kernel/fork.c
> > etc
> >
> > Acked-by: Joe Perches <joe@perches.com>
> > Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
> >  .clang-format | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > Resending outside the merge window with no change..
> >
> > If there is no clear upstream path for this file (it has no
> > MAINTAINERS entry?) I could take it to Linus via the rdma.git tree, eg
> 
> We can add an specific entry, yeah. Is there any policy for "general
> files" (or some general/catch-all entry)?
> 
> > as a 'collectively maintained' file.
> 
> As you prefer -- I can also pick it up through auxdisplay; but I am
> not sure if we should put it in any "unrelated" tree, though. (Since
> the file will not probably receive many patches, I originally thought
> that it would be picked up by Andrew or some other "general" tree
> instead.)

Well, I'd rather you take it as the owner of the file, honestly :)
Along with a MAINTAINERS update...

I also don't know too well what the policy is for these sorts of files
- other catch all files like kernel.h I run through rdma.git from time
to time, but that is in relation to patches that depend on them..

> > Would prefer Miguel's Ack to do that though. Looks like Andrew Morton
> > took the original patch introducing the file?
> 
> Yep, I sent it to Andrew and he kindly picked it up. Probably he
> didn't notice this one.
> 
> As for the patch:
> 
> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>

Lets give Andrew some time, he is probably very busy. If it gets to
rc5 without it getting picked up one of us can grab it instead to help
out..

Thanks,
Jason

Re: [PATCH RESEND] clang-format: Set IndentWrappedFunctionNames false

[Miguel Ojeda]

On Tue, Jun 26, 2018 at 9:33 PM, Jason Gunthorpe <jgg@mellanox.com> wrote:
> On Tue, Jun 26, 2018 at 05:05:40PM +0200, Miguel Ojeda wrote:
>> Hi,
>>
>> On Tue, Jun 26, 2018 at 12:44 AM, Jason Gunthorpe <jgg@mellanox.com> wrote:
>> > The true option causes this indenting for functions:
>> >
>> > static struct something_very_very_long *
>> >     function(void *arg)
>> > {
>> >
>> > While a quick survey suggests that the usual Linux fallback is the GNU
>> > style:
>> >
>> > static struct something_very_very_long *
>> > function(void *arg)
>> > {
>> >
>> > Eg as seen in:
>> >
>> > kernel/cpu.c
>> > kernel/fork.c
>> > etc
>> >
>> > Acked-by: Joe Perches <joe@perches.com>
>> > Signed-off-by: Jason Gunthorpe <jgg@mellanox.com>
>> >  .clang-format | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > Resending outside the merge window with no change..
>> >
>> > If there is no clear upstream path for this file (it has no
>> > MAINTAINERS entry?) I could take it to Linus via the rdma.git tree, eg
>>
>> We can add an specific entry, yeah. Is there any policy for "general
>> files" (or some general/catch-all entry)?
>>
>> > as a 'collectively maintained' file.
>>
>> As you prefer -- I can also pick it up through auxdisplay; but I am
>> not sure if we should put it in any "unrelated" tree, though. (Since
>> the file will not probably receive many patches, I originally thought
>> that it would be picked up by Andrew or some other "general" tree
>> instead.)
>
> Well, I'd rather you take it as the owner of the file, honestly :)
> Along with a MAINTAINERS update...

OK -- I will send the MAINTAINERS update patch :)

>
> I also don't know too well what the policy is for these sorts of files
> - other catch all files like kernel.h I run through rdma.git from time
> to time, but that is in relation to patches that depend on them..
>
>> > Would prefer Miguel's Ack to do that though. Looks like Andrew Morton
>> > took the original patch introducing the file?
>>
>> Yep, I sent it to Andrew and he kindly picked it up. Probably he
>> didn't notice this one.
>>
>> As for the patch:
>>
>> Acked-by: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>
>
> Lets give Andrew some time, he is probably very busy. If it gets to
> rc5 without it getting picked up one of us can grab it instead to help
> out..

Sure! :)

(and thanks!)

Cheers,
Miguel

>
> Thanks,
> Jason