clang-format: Set IndentWrappedFunctionNames false

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 <[email protected]>

Signed-off-by Jason Gunthorpe <[email protected]>

---
 .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

.clang-format +1 -2

index faffc0d5af4eeb..1d5da22e0ba50c 100644
@@ -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

Hi,

Quoted 21 lines · 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 <[email protected]>

Signed-off-by Jason Gunthorpe <[email protected]>

Quoted 7 lines

 .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)?

Quoted 1 line

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.)

Quoted 2 lines

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 <[email protected]>

Quoted 37 lines · Miguel Ojeda

Hi,

Quoted 21 lines · 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 <[email protected]>

Signed-off-by Jason Gunthorpe <[email protected]>

Quoted 7 lines

 .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)?

Quoted 1 line

as a 'collectively maintained' file.

Quoted 5 lines

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..

Quoted 6 lines

Quoted 2 lines

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.

Quoted 3 lines

As for the patch:

Acked-by Miguel Ojeda <[email protected]>

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