subject:"Re\: Nuttx Code Formatter Progress \[Was RE\: Should we relax precheck a little bit\?\]"

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-17 Thread Adam Feuer

David,

Here' the draft PR, marked [Do Not Merge]:

https://github.com/apache/incubator-nuttx/pull/583

-adam

On Tue, Mar 17, 2020 at 12:40 PM David Sidrane 
wrote:

> Hi Adam,
>
>
>
> See inline…
>
>
>
> *From:* Adam Feuer [mailto:a...@starcat.io]
> *Sent:* Tuesday, March 17, 2020 12:10 PM
> *To:* David Sidrane
> *Cc:* dev@nuttx.apache.org
> *Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax
> precheck a little bit?]
>
>
>
> David,
>
>
>
> Yes, I agree that it would be great if we can upstream the changes. I
> think that's possible, and I think we should try before making the decision
> to maintain our own fork.
>
>
>
> Yes, I also agree that the current config fixes a bunch of things, but
> also messes up a lot of other things too.
>
>
>
> Re: # indenting. I am not sure I understand your comments about this. Are
> the NuttX Style Guide sections on indenting
> <https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#indentation>
> correct? If so, we can probably add clang-format options to support this
> style. If not, can we correct the Style Guide?
>
> [DBS] The correct thing to do is indent on nested #, but we have to ignore
> the #if defined (THIS FILE) So the next # is at Col1.
>
>
>
> This is the convention for thew old way of doing #pragma once
>
>
>
> #if !defined(this file)
>
> #define this file
>
>
>
> #define FOO
>
>
>
> #endif /* !defined(this file) */
>
>
>
> This is what you would infer from the Style Guide, but now looking at it I
> see it has been updated
>
>
>
> #if !defined(this file)
>
> #  define this file
>
>
>
> #  define FOO
>
>
>
> #endif /* !defined(this file) */
>
>
>
>
>
> Re: clang-format having a greater ROI, I think that's true if we can get
> it to work. It has a big community supporting it.
>
>
>
> I will create a PR for the .clang-format and a README, and mark it [Do Not
> Merge] and DRAFT PR. Do you also want me to include the formatted files
> under sched/?
>
> [DBS] Yep all of it. So we can review it and play with it all.
>
>
>
> cheers
>
> adam
>
>
>
>
>
> On Tue, Mar 17, 2020 at 5:56 AM David Sidrane 
> wrote:
>
> Adam,
>
>
>
> Thank you for putting in the effort on this!
>
>
>
> I only suggest forking incase the LLVM project finds Nuttx' CS not of
> value. It would be great if we can upstream the changes.
>
>
>
> If we make this a DNM (Do Not Merge) Pull request we can discuss in-line
> where the comments will have context. Just put [Do Not Merge] in the title
> and Leave it set at DRAFT PR.
>
>
>
> Hopefully everyone will understand that we are doing this to collaborate
> and add valuable feedback.
>
>
>
> My overall view is it fixed a bunch of stuff NxStyle does not even detect.
> But it messes up a bunch of things too.
>
>
>
> One issue is the # indenting. Since Nuttx does not allow the modern use of
> `#pragma once` the guard #if defs set the indent to 1 to start with. I
> remember getting lambasted for doing this after reading the CS and
> following it. So we will need a -nuttx-option to set the indent to -1 and
> then only indent for > 0.
>
>
>
> Let's continue to take it apart in the PR and see what the level of effort
> would be to get it in shape.
>
>
>
> Personally, I am not afflicted with NIH syndrome, I value others quality
> tools, and I would rather put the effort in to this mature tool than
> Nxstyle, as the ROI will be much, much greater.
>
>
>
> David
>
>
>
>
>
>
>
> *From:* Adam Feuer [mailto:a...@starcat.io]
> *Sent:* Monday, March 16, 2020 3:35 PM
> *To:* David Sidrane; dev@nuttx.apache.org
> *Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax
> precheck a little bit?]
>
>
>
> Here's a Github compare with .clang-format file and the results when
> clang-format-9 is run on all the files under sched/:
>
>
>
>
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched
>
>
>
> If anyone has comments or observations I would love to know them.
>
>
>
> -adam
>
>
>
> On Mon, Mar 16, 2020 at 3:23 PM Adam Feuer  wrote:
>
> David,
>
>
>
> It would be a --style=NuttX option on the command line, and a set of
> configurations. But yes that might be the way to go. I don't think forking
> it would be the right thing, if we can modify it to do what we want, we
> should be able to add options that are configurable, submit PRs and get
> them merge

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-17 Thread Gregory Nutt





Re: # indenting. I am not sure I understand your comments about this. Are
the NuttX Style Guide sections on indenting

correct? If so, we can probably add clang-format options to support this
style. If not, can we correct the Style Guide?

[DBS] The correct thing to do is indent on nested #, but we have to ignore
the #if defined (THIS FILE) So the next # is at Col1.
You also have to ignore # indentation in the code sections of the 
files.  They are not indented because the indentation interferes with C 
indentation and makes the files unreadable.  Per coding standard.

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-17 Thread David Sidrane

Hi Adam,

See inline…

*From:* Adam Feuer [mailto:a...@starcat.io]
*Sent:* Tuesday, March 17, 2020 12:10 PM
*To:* David Sidrane
*Cc:* dev@nuttx.apache.org
*Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax
precheck a little bit?]

David,

Yes, I agree that it would be great if we can upstream the changes. I think
that's possible, and I think we should try before making the decision to
maintain our own fork.

Yes, I also agree that the current config fixes a bunch of things, but also
messes up a lot of other things too.

Re: # indenting. I am not sure I understand your comments about this. Are
the NuttX Style Guide sections on indenting
<https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#indentation>
correct? If so, we can probably add clang-format options to support this
style. If not, can we correct the Style Guide?

[DBS] The correct thing to do is indent on nested #, but we have to ignore
the #if defined (THIS FILE) So the next # is at Col1.

This is the convention for thew old way of doing #pragma once

#if !defined(this file)

#define this file

#define FOO

#endif /* !defined(this file) */

This is what you would infer from the Style Guide, but now looking at it I
see it has been updated

#if !defined(this file)

# define this file

# define FOO

#endif /* !defined(this file) */

Re: clang-format having a greater ROI, I think that's true if we can get it
to work. It has a big community supporting it.

I will create a PR for the .clang-format and a README, and mark it [Do Not
Merge] and DRAFT PR. Do you also want me to include the formatted files
under sched/?

[DBS] Yep all of it. So we can review it and play with it all.

cheers

adam

On Tue, Mar 17, 2020 at 5:56 AM David Sidrane
wrote:

Adam,

Thank you for putting in the effort on this!

I only suggest forking incase the LLVM project finds Nuttx' CS not of
value. It would be great if we can upstream the changes.

If we make this a DNM (Do Not Merge) Pull request we can discuss in-line
where the comments will have context. Just put [Do Not Merge] in the title
and Leave it set at DRAFT PR.

Hopefully everyone will understand that we are doing this to collaborate
and add valuable feedback.

My overall view is it fixed a bunch of stuff NxStyle does not even detect.
But it messes up a bunch of things too.

One issue is the # indenting. Since Nuttx does not allow the modern use of
`#pragma once` the guard #if defs set the indent to 1 to start with. I
remember getting lambasted for doing this after reading the CS and
following it. So we will need a -nuttx-option to set the indent to -1 and
then only indent for > 0.

Let's continue to take it apart in the PR and see what the level of effort
would be to get it in shape.

Personally, I am not afflicted with NIH syndrome, I value others quality
tools, and I would rather put the effort in to this mature tool than
Nxstyle, as the ROI will be much, much greater.

David

*From:* Adam Feuer [mailto:a...@starcat.io]
*Sent:* Monday, March 16, 2020 3:35 PM
*To:* David Sidrane; dev@nuttx.apache.org
*Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax
precheck a little bit?]

Here's a Github compare with .clang-format file and the results when
clang-format-9 is run on all the files under sched/:

https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched

If anyone has comments or observations I would love to know them.

-adam

On Mon, Mar 16, 2020 at 3:23 PM Adam Feuer wrote:

David,

It would be a --style=NuttX option on the command line, and a set of
configurations. But yes that might be the way to go. I don't think forking
it would be the right thing, if we can modify it to do what we want, we
should be able to add options that are configurable, submit PRs and get
them merged. Then the features can be used and maintained by everyone who
uses clang-format, a very large userbase, that would be a very good option.

I think it can work... I'll post link to what it can currently do in sched/
so we can look at the differences to see how close we are.

-adam

On Sun, Mar 15, 2020 at 6:49 AM David Sidrane
wrote:

Hi Adam,

Hmmm…Would the shortest path, on this issue, be to add some -NuttX options
and submit a PR to upstream or Fork it?

It may be that time spent training Clang-format is better than time spent
on nstyle, as it is a "shorter haul" with a much, much greater return.

David

*From:* Adam Feuer [mailto:a...@starcat.io]
*Sent:* Saturday, March 14, 2020 1:59 PM
*To:* dev@nuttx.apache.org; david.sidr...@nscdg.com; w8j...@gmail.com
*Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax
precheck a little bit?]

I looked at the clang-format source code. It has trouble aligning the = of
a -= or +=. I easily made a change to align on the - or + of a -= or +=,
but som

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-17 Thread Adam Feuer

David,

Yes, I agree that it would be great if we can upstream the changes. I think
that's possible, and I think we should try before making the decision to
maintain our own fork.

Yes, I also agree that the current config fixes a bunch of things, but also
messes up a lot of other things too.

Re: # indenting. I am not sure I understand your comments about this. Are
the NuttX Style Guide sections on indenting
<https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#indentation>
correct? If so, we can probably add clang-format options to support this
style. If not, can we correct the Style Guide?

Re: clang-format having a greater ROI, I think that's true if we can get it
to work. It has a big community supporting it.

I will create a PR for the .clang-format and a README, and mark it [Do Not
Merge] and DRAFT PR. Do you also want me to include the formatted files
under sched/?

cheers
adam


On Tue, Mar 17, 2020 at 5:56 AM David Sidrane 
wrote:

> Adam,
>
>
>
> Thank you for putting in the effort on this!
>
>
>
> I only suggest forking incase the LLVM project finds Nuttx' CS not of
> value. It would be great if we can upstream the changes.
>
>
>
> If we make this a DNM (Do Not Merge) Pull request we can discuss in-line
> where the comments will have context. Just put [Do Not Merge] in the title
> and Leave it set at DRAFT PR.
>
>
>
> Hopefully everyone will understand that we are doing this to collaborate
> and add valuable feedback.
>
>
>
> My overall view is it fixed a bunch of stuff NxStyle does not even detect.
> But it messes up a bunch of things too.
>
>
>
> One issue is the # indenting. Since Nuttx does not allow the modern use of
> `#pragma once` the guard #if defs set the indent to 1 to start with. I
> remember getting lambasted for doing this after reading the CS and
> following it. So we will need a -nuttx-option to set the indent to -1 and
> then only indent for > 0.
>
>
>
> Let's continue to take it apart in the PR and see what the level of effort
> would be to get it in shape.
>
>
>
> Personally, I am not afflicted with NIH syndrome, I value others quality
> tools, and I would rather put the effort in to this mature tool than
> Nxstyle, as the ROI will be much, much greater.
>
>
>
> David
>
>
>
>
>
>
>
> *From:* Adam Feuer [mailto:a...@starcat.io]
> *Sent:* Monday, March 16, 2020 3:35 PM
> *To:* David Sidrane; dev@nuttx.apache.org
> *Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax
> precheck a little bit?]
>
>
>
> Here's a Github compare with .clang-format file and the results when
> clang-format-9 is run on all the files under sched/:
>
>
>
>
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched
>
>
>
> If anyone has comments or observations I would love to know them.
>
>
>
> -adam
>
>
>
> On Mon, Mar 16, 2020 at 3:23 PM Adam Feuer  wrote:
>
> David,
>
>
>
> It would be a --style=NuttX option on the command line, and a set of
> configurations. But yes that might be the way to go. I don't think forking
> it would be the right thing, if we can modify it to do what we want, we
> should be able to add options that are configurable, submit PRs and get
> them merged. Then the features can be used and maintained by everyone who
> uses clang-format, a very large userbase, that would be a very good option.
>
>
>
> I think it can work... I'll post link to what it can currently do in
> sched/ so we can look at the differences to see how close we are.
>
>
>
> -adam
>
>
>
> On Sun, Mar 15, 2020 at 6:49 AM David Sidrane 
> wrote:
>
> Hi Adam,
>
>
>
> Hmmm…Would the shortest path, on this issue, be to add some -NuttX options
> and submit a PR to upstream or Fork it?
>
>
>
> It may be that time spent training Clang-format is better than time spent
> on nstyle, as it is a "shorter haul" with a much, much greater return.
>
>
>
> David
>
>
>
> *From:* Adam Feuer [mailto:a...@starcat.io]
> *Sent:* Saturday, March 14, 2020 1:59 PM
> *To:* dev@nuttx.apache.org; david.sidr...@nscdg.com; w8j...@gmail.com
> *Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax
> precheck a little bit?]
>
>
>
> I looked at the clang-format source code. It has trouble aligning the = of
> a -= or +=. I easily made a change to align on the - or + of a -= or +=,
> but some work will be necessary to give an option that aligns the way the
> nuttx code does it. Will think more about it.
>
>
>
> -adam
>
>
>
>
>
> On Sat, Mar 14, 2020 at 1:21 PM Adam Feuer  w

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-17 Thread David Sidrane

Adam,

Thank you for putting in the effort on this!

I only suggest forking incase the LLVM project finds Nuttx' CS not of
value. It would be great if we can upstream the changes.

If we make this a DNM (Do Not Merge) Pull request we can discuss in-line
where the comments will have context. Just put [Do Not Merge] in the title
and Leave it set at DRAFT PR.

Hopefully everyone will understand that we are doing this to collaborate
and add valuable feedback.

My overall view is it fixed a bunch of stuff NxStyle does not even detect.
But it messes up a bunch of things too.

Let's continue to take it apart in the PR and see what the level of effort
would be to get it in shape.

Personally, I am not afflicted with NIH syndrome, I value others quality
tools, and I would rather put the effort in to this mature tool than
Nxstyle, as the ROI will be much, much greater.

David

Here's a Github compare with .clang-format file and the results when
clang-format-9 is run on all the files under sched/:

https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched

If anyone has comments or observations I would love to know them.

-adam

On Mon, Mar 16, 2020 at 3:23 PM Adam Feuer wrote:

David,

I think it can work... I'll post link to what it can currently do in sched/
so we can look at the differences to see how close we are.

-adam

On Sun, Mar 15, 2020 at 6:49 AM David Sidrane
wrote:

Hi Adam,

Hmmm…Would the shortest path, on this issue, be to add some -NuttX options
and submit a PR to upstream or Fork it?

It may be that time spent training Clang-format is better than time spent
on nstyle, as it is a "shorter haul" with a much, much greater return.

David

I looked at the clang-format source code. It has trouble aligning the = of
a -= or +=. I easily made a change to align on the - or + of a -= or +=,
but some work will be necessary to give an option that aligns the way the
nuttx code does it. Will think more about it.

-adam

On Sat, Mar 14, 2020 at 1:21 PM Adam Feuer wrote:

David, Maciej, Peter,

Thanks for your help!

IndentPPDirectives: PPDIS_AfterHash works. The actual syntax for the
.clang-format file is this:

IndentPPDirectives: AfterHash

That makes things a lot better. There are a bunch of inconsistent macro
indents under sched/ though— many macros indent ok, but there are a bunch
that don't. Not sure what to do about that... are they really inconsistent?
If so maybe we make a small PR that fixes the inconsistent indents?

What seems to be next:

· alignment of successive expressions

reltime.tv_nsec += NSEC_PER_SEC;
- reltime.tv_sec -= 1;
+ reltime.tv_sec -= 1;

· alignment of comment blocks — to make sure they line up with the next
comment line in the block

For instance:

- /* The resulting set is the intersection of the current set and
+/* The resulting set is the intersection of the current set and
* the complement of the signal set pointed to by _set.
*/

· evaluating inconsistencies in the alignment style... some expressions
and declarations are aligned, others are not... I need to consult the style
guide to see what it says.

I'm using clang-format-9. Here's the command lines I'm running to generate
and look at the changes (in the nutt/ dir):

$ find ./sched/ -iname "*.h" -or -iname "*.c" | xargs clang-format-9 -i
-style=file

$ git diff

$ # change .clang-format

$ git stash; git stash drop

Here's my .clang format file as of now:

---
Language:Cpp
AccessModifierOffset: -2
AlignAfterOpenBracket: Align
AlignConsecuti

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-16 Thread Gregory Nutt





Yes, it may be horrible. Please don't look at the results right now then...
this is a work in progress.


Okay.  Thanks for clarifying that.  nxstyle is still your friend.

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-16 Thread Gregory Nutt





 ...  It is simply not following the NuttX coding standard.

Perhaps what you should do is also run the modified files through 
nxstyle.  nxstyle, like most tools, is imperfect but it is the yardstick 
we use to evaluating conformance to the coding standard now.  Certainly 
a first step would be to run your tool then run nxstyle immediately 
afterward.  nxstyle should not detect any problems if you are on the 
right track (currently, I think nxstyle would generate reams of 
complaints about the output).


If the generated code cannot make it through nxstyle, then it is not 
ready to be reviewed or considered in anyway.


Making it through nxstyle does not mean that the tools is working 
correctly, however.  There are many things not checked by nxstyle, but 
this would give you a starting point for getting these huge issues out 
of the way.  That would then be an appropriate time to review the 
remaining diffs.


Greg

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-16 Thread Adam Feuer

Hi Greg,

Yes, it may be horrible. Please don't look at the results right now then...
this is a work in progress.

I'm just trying to do the development and coordination in the open, as the
Apache folks have asked— no off-list communication, right?

I just posted these so David and others could easily look at the output,
not because I was going to submit any kind of PR. It seems like it should
be ok to show work-in-progress here. Otherwise how can we collaborate?

When it's more fully baked, we'll let you know. :)

-adam

On Mon, Mar 16, 2020 at 4:36 PM Gregory Nutt  wrote:

> I mentioned in the previous email that the tools was screwing up
> vertifcal alignment is places where it is recommend and in places where
> is it required.  Here is an example of the later:
>
>   * sched/irq/irq.h
> <
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched#diff-08538ebd3dc53f5f85f131c24c84be9d
> >,
> beginning at line 75 all veritical alignment of right hand comments
> lost.
>
> A few more:
>
>   * clock_timespec_subtract.c
> <
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched#diff-906c272ac7c0b95506056c0c431ab276
> >,
> insanity at line 69.  Similar nonsense at group_setuid.c
> <
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched#diff-f39b80ac9e4440e2d2889ef55425f3ef
> >
> line 76, group_signal.c
> <
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched#diff-750c9acf01eefd4c69e3186ceb9519bd
> >
> , line 90 and other places
>   * nx_smpstart.c,
> <
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched#diff-8195c6cbcb792a1f2e6b337039a1d111
> >line
> 120, removes required spacing after semi-colon
>   * It seems to screw up the indenttaion after any conditional logic.
> Like nx_bringup.c
> <
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched#diff-9aa86408017fde10647798c88d4c62b0
> >,
> line 79-110
>   * group_malloc.c,
> <
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched#diff-6cb24cb106c424372fc4dd44e55b8a07
> >line
> 51, screw sup indentation of conditional.  also group_zalloc.c
> <
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched#diff-87884d55782f00d26a012863add30407
> >,
> line 47 and other places
>   * group_setupidlefiles.c
> <
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched#diff-aa3bb2f5a7f4db9b96218e96098ea53c
> >,
> line 118 more destruction of indentation.  Also nx_bringup.c
> <
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched#diff-9aa86408017fde10647798c88d4c62b0
> >,
> line 74 and other places
>   * nx_start.c
> <
> https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched#diff-e36621b38d26a5eeb9f0c9c779931e7b
> >
> , all braces trashed beginning at line 253.  Right alignment of all
> comments lost.
>
> I can't look at any more.  Occasionally I see a new error and suspect
> that there are more.  But these I have describe account for at least
> most.  I see these kinds of errors in 100's perhaps 1000's of places.
> Lots of indentation and alignment errors.  It is simply not following
> the NuttX coding standard.
>
>
>

-- 
Adam Feuer

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-16 Thread Gregory Nutt

I mentioned in the previous email that the tools was screwing up 
vertifcal alignment is places where it is recommend and in places where 
is it required.  Here is an example of the later:


 * sched/irq/irq.h
   
,
   beginning at line 75 all veritical alignment of right hand comments
   lost.

A few more:

 * clock_timespec_subtract.c
   
,
   insanity at line 69.  Similar nonsense at group_setuid.c
   

   line 76, group_signal.c
   

   , line 90 and other places
 * nx_smpstart.c,
   
line
   120, removes required spacing after semi-colon
 * It seems to screw up the indenttaion after any conditional logic. 
   Like nx_bringup.c
   
,
   line 79-110
 * group_malloc.c,
   
line
   51, screw sup indentation of conditional.  also group_zalloc.c
   
,
   line 47 and other places
 * group_setupidlefiles.c
   
,
   line 118 more destruction of indentation.  Also nx_bringup.c
   
,
   line 74 and other places
 * nx_start.c
   

   , all braces trashed beginning at line 253.  Right alignment of all
   comments lost.

I can't look at any more.  Occasionally I see a new error and suspect 
that there are more.  But these I have describe account for at least 
most.  I see these kinds of errors in 100's perhaps 1000's of places.  
Lots of indentation and alignment errors.  It is simply not following 
the NuttX coding standard.

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-16 Thread Gregory Nutt

Here's a Github compare with .clang-format file and the results when
clang-format-9 is run on all the files under sched/:

https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched

If anyone has comments or observations I would love to know them.

That is horrible! Not even close. It is doing massive corruption of
the original files. I appreciate that this is a work in progress, but
it is not close enough yet for any kind of review. At present, it just
does massive corruption of files.

* It is destroying indentation randomly (like line 71 of clock.h).
* It is destroying the careful alignment of prototypes like line 90
and beyond.
* It removes all vertical alignment, some optional and some required.
* This is crazy. It moved a left bracket onto the same line as a
definition (line 54 of clock_dow.c)
* in clock_systimer.c, pre-processor definitions must not be indented
when use in the code section (numerous places).
https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#indentation
* in clock_systimespec.c, line 134. The indentation was correct. The
tool ruined it. Also line 142 it again destroys the proper
alignment of the first line of C comment blocks. Numerous other places.
* in clock_timekeeping.c, line 88 abd line 105 spurious destruction of
vertical alignment.
* And on an on.. There is too much there to review.

We agreed when we started this that the success criteria was no
differences from the original. I could see compromising a few find
details, but this is not close. This is the worst formatting
programming I have seen. All of the formatters under tools are better
and none of them are acceptable.

I don't know if these can be fixed or not but please do not commit
anything now. This is not ready. It is just too wrong and I would not
want anyone to use it.

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-16 Thread Adam Feuer

Here's a Github compare with .clang-format file and the results when
clang-format-9 is run on all the files under sched/:

https://github.com/apache/incubator-nuttx/compare/master...starcat-io:explore/clang-format-sched

If anyone has comments or observations I would love to know them.

-adam

On Mon, Mar 16, 2020 at 3:23 PM Adam Feuer  wrote:

> David,
>
> It would be a --style=NuttX option on the command line, and a set of
> configurations. But yes that might be the way to go. I don't think forking
> it would be the right thing, if we can modify it to do what we want, we
> should be able to add options that are configurable, submit PRs and get
> them merged. Then the features can be used and maintained by everyone who
> uses clang-format, a very large userbase, that would be a very good option.
>
> I think it can work... I'll post link to what it can currently do in
> sched/ so we can look at the differences to see how close we are.
>
> -adam
>
> On Sun, Mar 15, 2020 at 6:49 AM David Sidrane 
> wrote:
>
>> Hi Adam,
>>
>>
>>
>> Hmmm…Would the shortest path, on this issue, be to add some -NuttX
>> options and submit a PR to upstream or Fork it?
>>
>>
>>
>> It may be that time spent training Clang-format is better than time spent
>> on nstyle, as it is a "shorter haul" with a much, much greater return.
>>
>>
>>
>> David
>>
>>
>>
>> *From:* Adam Feuer [mailto:a...@starcat.io]
>> *Sent:* Saturday, March 14, 2020 1:59 PM
>> *To:* dev@nuttx.apache.org; david.sidr...@nscdg.com; w8j...@gmail.com
>> *Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax
>> precheck a little bit?]
>>
>>
>>
>> I looked at the clang-format source code. It has trouble aligning the =
>> of a -= or +=. I easily made a change to align on the - or + of a -= or +=,
>> but some work will be necessary to give an option that aligns the way the
>> nuttx code does it. Will think more about it.
>>
>>
>>
>> -adam
>>
>>
>>
>>
>>
>> On Sat, Mar 14, 2020 at 1:21 PM Adam Feuer  wrote:
>>
>> David, Maciej, Peter,
>>
>>
>>
>> Thanks for your help!
>>
>>
>>
>> IndentPPDirectives: PPDIS_AfterHash works. The actual syntax for the
>> .clang-format file is this:
>>
>>
>>
>> IndentPPDirectives: AfterHash
>>
>>
>>
>> That makes things a lot better. There are a bunch of inconsistent macro
>> indents under sched/ though— many macros indent ok, but there are a bunch
>> that don't. Not sure what to do about that... are they really inconsistent?
>> If so maybe we make a small PR that fixes the inconsistent indents?
>>
>>
>>
>> What seems to be next:
>>
>> ·  alignment of successive expressions
>>
>>reltime.tv_nsec += NSEC_PER_SEC;
>> -  reltime.tv_sec  -= 1;
>> +  reltime.tv_sec -= 1;
>>
>> ·  alignment of comment blocks — to make sure they line up with the
>> next comment line in the block
>>
>> For instance:
>>
>>
>>
>> -  /* The resulting set is the intersection of the current set and
>> +/* The resulting set is the intersection of the current set
>> and
>> * the complement of the signal set pointed to by _set.
>> */
>>
>> ·  evaluating inconsistencies in the alignment style... some expressions
>> and declarations are aligned, others are not... I need to consult the style
>> guide to see what it says.
>>
>>
>>
>> I'm using clang-format-9. Here's the command lines I'm running to
>> generate and look at the changes (in the nutt/ dir):
>>
>>
>>
>> $ find ./sched/ -iname "*.h" -or -iname "*.c" | xargs clang-format-9 -i
>> -style=file
>>
>> $ git diff
>>
>> $ # change .clang-format
>>
>> $ git stash; git stash drop
>>
>> 
>>
>>
>>
>> Here's my .clang format file as of now:
>>
>>
>>
>> ---
>> Language:Cpp
>> AccessModifierOffset: -2
>> AlignAfterOpenBracket: Align
>> AlignConsecutiveMacros: true
>> AlignConsecutiveAssignments: true
>> AlignConsecutiveDeclarations: true
>> AlignEscapedNewlines: DontAlign
>> AlignOperands:   true
>> AlignTrailingComments: true
>> AllowAllArgumentsOnNextLine: true
>> AllowAllConstructorInitializersOnNextLine: true
>> AllowAllParametersOfDeclarationOnNextLine: true
>>

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-16 Thread Adam Feuer

David,

It would be a --style=NuttX option on the command line, and a set of
configurations. But yes that might be the way to go. I don't think forking
it would be the right thing, if we can modify it to do what we want, we
should be able to add options that are configurable, submit PRs and get
them merged. Then the features can be used and maintained by everyone who
uses clang-format, a very large userbase, that would be a very good option.

I think it can work... I'll post link to what it can currently do in sched/
so we can look at the differences to see how close we are.

-adam

On Sun, Mar 15, 2020 at 6:49 AM David Sidrane 
wrote:

> Hi Adam,
>
>
>
> Hmmm…Would the shortest path, on this issue, be to add some -NuttX options
> and submit a PR to upstream or Fork it?
>
>
>
> It may be that time spent training Clang-format is better than time spent
> on nstyle, as it is a "shorter haul" with a much, much greater return.
>
>
>
> David
>
>
>
> *From:* Adam Feuer [mailto:a...@starcat.io]
> *Sent:* Saturday, March 14, 2020 1:59 PM
> *To:* dev@nuttx.apache.org; david.sidr...@nscdg.com; w8j...@gmail.com
> *Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax
> precheck a little bit?]
>
>
>
> I looked at the clang-format source code. It has trouble aligning the = of
> a -= or +=. I easily made a change to align on the - or + of a -= or +=,
> but some work will be necessary to give an option that aligns the way the
> nuttx code does it. Will think more about it.
>
>
>
> -adam
>
>
>
>
>
> On Sat, Mar 14, 2020 at 1:21 PM Adam Feuer  wrote:
>
> David, Maciej, Peter,
>
>
>
> Thanks for your help!
>
>
>
> IndentPPDirectives: PPDIS_AfterHash works. The actual syntax for the
> .clang-format file is this:
>
>
>
> IndentPPDirectives: AfterHash
>
>
>
> That makes things a lot better. There are a bunch of inconsistent macro
> indents under sched/ though— many macros indent ok, but there are a bunch
> that don't. Not sure what to do about that... are they really inconsistent?
> If so maybe we make a small PR that fixes the inconsistent indents?
>
>
>
> What seems to be next:
>
> ·  alignment of successive expressions
>
>reltime.tv_nsec += NSEC_PER_SEC;
> -  reltime.tv_sec  -= 1;
> +  reltime.tv_sec -= 1;
>
> ·  alignment of comment blocks — to make sure they line up with the next
> comment line in the block
>
> For instance:
>
>
>
> -  /* The resulting set is the intersection of the current set and
> +/* The resulting set is the intersection of the current set
> and
> * the complement of the signal set pointed to by _set.
> */
>
> ·  evaluating inconsistencies in the alignment style... some expressions
> and declarations are aligned, others are not... I need to consult the style
> guide to see what it says.
>
>
>
> I'm using clang-format-9. Here's the command lines I'm running to generate
> and look at the changes (in the nutt/ dir):
>
>
>
> $ find ./sched/ -iname "*.h" -or -iname "*.c" | xargs clang-format-9 -i
> -style=file
>
> $ git diff
>
> $ # change .clang-format
>
> $ git stash; git stash drop
>
> 
>
>
>
> Here's my .clang format file as of now:
>
>
>
> ---
> Language:Cpp
> AccessModifierOffset: -2
> AlignAfterOpenBracket: Align
> AlignConsecutiveMacros: true
> AlignConsecutiveAssignments: true
> AlignConsecutiveDeclarations: true
> AlignEscapedNewlines: DontAlign
> AlignOperands:   true
> AlignTrailingComments: true
> AllowAllArgumentsOnNextLine: true
> AllowAllConstructorInitializersOnNextLine: true
> AllowAllParametersOfDeclarationOnNextLine: true
> AllowShortBlocksOnASingleLine: false
> AllowShortCaseLabelsOnASingleLine: false
> AllowShortFunctionsOnASingleLine: All
> AllowShortLambdasOnASingleLine: All
> AllowShortIfStatementsOnASingleLine: Never
> AllowShortLoopsOnASingleLine: false
> AlwaysBreakAfterDefinitionReturnType: None
> AlwaysBreakAfterReturnType: None
> AlwaysBreakBeforeMultilineStrings: false
> AlwaysBreakTemplateDeclarations: MultiLine
> BinPackArguments: true
> BinPackParameters: true
> BraceWrapping:
>   AfterCaseLabel:  false
>   AfterClass:  false
>   AfterControlStatement: true
>   AfterEnum:   true
>   AfterFunction:   true
>   AfterNamespace:  false
>   AfterObjCDeclaration: false
>   AfterStruct: true
>   AfterUnion:  true
>   AfterExternBlock: false
>   BeforeCatch: false
>   BeforeElse:  true
>   IndentBraces:true
>   SplitEmptyFunction: true
&g

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-15 Thread David Sidrane

Hi Adam,



Hmmm…Would the shortest path, on this issue, be to add some -NuttX options
and submit a PR to upstream or Fork it?



It may be that time spent training Clang-format is better than time spent
on nstyle, as it is a "shorter haul" with a much, much greater return.



David



*From:* Adam Feuer [mailto:a...@starcat.io]
*Sent:* Saturday, March 14, 2020 1:59 PM
*To:* dev@nuttx.apache.org; david.sidr...@nscdg.com; w8j...@gmail.com
*Subject:* Re: Nuttx Code Formatter Progress [Was RE: Should we relax
precheck a little bit?]



I looked at the clang-format source code. It has trouble aligning the = of
a -= or +=. I easily made a change to align on the - or + of a -= or +=,
but some work will be necessary to give an option that aligns the way the
nuttx code does it. Will think more about it.



-adam





On Sat, Mar 14, 2020 at 1:21 PM Adam Feuer  wrote:

David, Maciej, Peter,



Thanks for your help!



IndentPPDirectives: PPDIS_AfterHash works. The actual syntax for the
.clang-format file is this:



IndentPPDirectives: AfterHash



That makes things a lot better. There are a bunch of inconsistent macro
indents under sched/ though— many macros indent ok, but there are a bunch
that don't. Not sure what to do about that... are they really inconsistent?
If so maybe we make a small PR that fixes the inconsistent indents?



What seems to be next:

·  alignment of successive expressions

   reltime.tv_nsec += NSEC_PER_SEC;
-  reltime.tv_sec  -= 1;
+  reltime.tv_sec -= 1;

·  alignment of comment blocks — to make sure they line up with the next
comment line in the block

For instance:



-  /* The resulting set is the intersection of the current set and
+/* The resulting set is the intersection of the current set and
* the complement of the signal set pointed to by _set.
*/

·  evaluating inconsistencies in the alignment style... some expressions
and declarations are aligned, others are not... I need to consult the style
guide to see what it says.



I'm using clang-format-9. Here's the command lines I'm running to generate
and look at the changes (in the nutt/ dir):



$ find ./sched/ -iname "*.h" -or -iname "*.c" | xargs clang-format-9 -i
-style=file

$ git diff

$ # change .clang-format

$ git stash; git stash drop





Here's my .clang format file as of now:



---
Language:Cpp
AccessModifierOffset: -2
AlignAfterOpenBracket: Align
AlignConsecutiveMacros: true
AlignConsecutiveAssignments: true
AlignConsecutiveDeclarations: true
AlignEscapedNewlines: DontAlign
AlignOperands:   true
AlignTrailingComments: true
AllowAllArgumentsOnNextLine: true
AllowAllConstructorInitializersOnNextLine: true
AllowAllParametersOfDeclarationOnNextLine: true
AllowShortBlocksOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: false
AllowShortFunctionsOnASingleLine: All
AllowShortLambdasOnASingleLine: All
AllowShortIfStatementsOnASingleLine: Never
AllowShortLoopsOnASingleLine: false
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakAfterReturnType: None
AlwaysBreakBeforeMultilineStrings: false
AlwaysBreakTemplateDeclarations: MultiLine
BinPackArguments: true
BinPackParameters: true
BraceWrapping:
  AfterCaseLabel:  false
  AfterClass:  false
  AfterControlStatement: true
  AfterEnum:   true
  AfterFunction:   true
  AfterNamespace:  false
  AfterObjCDeclaration: false
  AfterStruct: true
  AfterUnion:  true
  AfterExternBlock: false
  BeforeCatch: false
  BeforeElse:  true
  IndentBraces:true
  SplitEmptyFunction: true
  SplitEmptyRecord: true
  SplitEmptyNamespace: true
BreakBeforeBinaryOperators: None
BreakBeforeBraces: Custom
BreakBeforeInheritanceComma: false
BreakInheritanceList: BeforeColon
BreakBeforeTernaryOperators: true
BreakConstructorInitializersBeforeComma: false
BreakConstructorInitializers: BeforeColon
BreakAfterJavaFieldAnnotations: false
BreakStringLiterals: true
ColumnLimit: 0
CommentPragmas:  '^ IWYU pragma:'
CompactNamespaces: false
ConstructorInitializerAllOnOneLineOrOnePerLine: false
ConstructorInitializerIndentWidth: 4
ContinuationIndentWidth: 0
Cpp11BracedListStyle: false
DerivePointerAlignment: false
DisableFormat:   false
ExperimentalAutoDetectBinPacking: false
FixNamespaceComments: false
ForEachMacros:
  - foreach
  - Q_FOREACH
  - BOOST_FOREACH
IncludeBlocks:   Preserve
IncludeCategories:
  - Regex:   '^"(llvm|llvm-c|clang|clang-c)/'
Priority:2
  - Regex:   '^(<|"(gtest|gmock|isl|json)/)'
Priority:3
  - Regex:   '.*'
Priority:1
IncludeIsMainRegex: '(Test)?$'
IndentCaseLabels: true
IndentPPDirectives: AfterHash
IndentWidth: 2
IndentWrappedFunctionNames: false
JavaScriptQuotes: Leave
JavaScriptWrapImports: true
KeepEmptyLinesAtTheStartOfBlocks: true
MacroBlockBegin: ''
MacroBlockEnd:   '&#

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-14 Thread Adam Feuer

I looked at the clang-format source code. It has trouble aligning the = of
a -= or +=. I easily made a change to align on the - or + of a -= or +=,
but some work will be necessary to give an option that aligns the way the
nuttx code does it. Will think more about it.

-adam


On Sat, Mar 14, 2020 at 1:21 PM Adam Feuer  wrote:

> David, Maciej, Peter,
>
> Thanks for your help!
>
> IndentPPDirectives: PPDIS_AfterHash works. The actual syntax for the
> .clang-format file is this:
>
> IndentPPDirectives: AfterHash
>
> That makes things a lot better. There are a bunch of inconsistent macro
> indents under sched/ though— many macros indent ok, but there are a bunch
> that don't. Not sure what to do about that... are they really inconsistent?
> If so maybe we make a small PR that fixes the inconsistent indents?
>
> What seems to be next:
>
>- alignment of successive expressions
>
>reltime.tv_nsec += NSEC_PER_SEC;
>> -  reltime.tv_sec  -= 1;
>> +  reltime.tv_sec -= 1;
>>
>
>- alignment of comment blocks — to make sure they line up with the
>next comment line in the block
>
> For instance:
>
> -  /* The resulting set is the intersection of the current set and
>> +/* The resulting set is the intersection of the current set
>> and
>> * the complement of the signal set pointed to by _set.
>> */
>>
>
>- evaluating inconsistencies in the alignment style... some
>expressions and declarations are aligned, others are not... I need to
>consult the style guide to see what it says.
>
>
> I'm using clang-format-9. Here's the command lines I'm running to generate
> and look at the changes (in the nutt/ dir):
>
> $ find ./sched/ -iname "*.h" -or -iname "*.c" | xargs clang-format-9 -i
> -style=file
> $ git diff
> $ # change .clang-format
> $ git stash; git stash drop
> 
>
> Here's my .clang format file as of now:
>
> ---
> Language:Cpp
> AccessModifierOffset: -2
> AlignAfterOpenBracket: Align
> AlignConsecutiveMacros: true
> AlignConsecutiveAssignments: true
> AlignConsecutiveDeclarations: true
> AlignEscapedNewlines: DontAlign
> AlignOperands:   true
> AlignTrailingComments: true
> AllowAllArgumentsOnNextLine: true
> AllowAllConstructorInitializersOnNextLine: true
> AllowAllParametersOfDeclarationOnNextLine: true
> AllowShortBlocksOnASingleLine: false
> AllowShortCaseLabelsOnASingleLine: false
> AllowShortFunctionsOnASingleLine: All
> AllowShortLambdasOnASingleLine: All
> AllowShortIfStatementsOnASingleLine: Never
> AllowShortLoopsOnASingleLine: false
> AlwaysBreakAfterDefinitionReturnType: None
> AlwaysBreakAfterReturnType: None
> AlwaysBreakBeforeMultilineStrings: false
> AlwaysBreakTemplateDeclarations: MultiLine
> BinPackArguments: true
> BinPackParameters: true
> BraceWrapping:
>   AfterCaseLabel:  false
>   AfterClass:  false
>   AfterControlStatement: true
>   AfterEnum:   true
>   AfterFunction:   true
>   AfterNamespace:  false
>   AfterObjCDeclaration: false
>   AfterStruct: true
>   AfterUnion:  true
>   AfterExternBlock: false
>   BeforeCatch: false
>   BeforeElse:  true
>   IndentBraces:true
>   SplitEmptyFunction: true
>   SplitEmptyRecord: true
>   SplitEmptyNamespace: true
> BreakBeforeBinaryOperators: None
> BreakBeforeBraces: Custom
> BreakBeforeInheritanceComma: false
> BreakInheritanceList: BeforeColon
> BreakBeforeTernaryOperators: true
> BreakConstructorInitializersBeforeComma: false
> BreakConstructorInitializers: BeforeColon
> BreakAfterJavaFieldAnnotations: false
> BreakStringLiterals: true
> ColumnLimit: 0
> CommentPragmas:  '^ IWYU pragma:'
> CompactNamespaces: false
> ConstructorInitializerAllOnOneLineOrOnePerLine: false
> ConstructorInitializerIndentWidth: 4
> ContinuationIndentWidth: 0
> Cpp11BracedListStyle: false
> DerivePointerAlignment: false
> DisableFormat:   false
> ExperimentalAutoDetectBinPacking: false
> FixNamespaceComments: false
> ForEachMacros:
>   - foreach
>   - Q_FOREACH
>   - BOOST_FOREACH
> IncludeBlocks:   Preserve
> IncludeCategories:
>   - Regex:   '^"(llvm|llvm-c|clang|clang-c)/'
> Priority:2
>   - Regex:   '^(<|"(gtest|gmock|isl|json)/)'
> Priority:3
>   - Regex:   '.*'
> Priority:1
> IncludeIsMainRegex: '(Test)?$'
> IndentCaseLabels: true
> IndentPPDirectives: AfterHash
> IndentWidth: 2
> IndentWrappedFunctionNames: false
> JavaScriptQuotes: Leave
> JavaScriptWrapImports: true
> KeepEmptyLinesAtTheStartOfBlocks: true
> MacroBlockBegin: ''
> MacroBlockEnd:   ''
> MaxEmptyLinesToKeep: 1
> NamespaceIndentation: None
> ObjCBinPackProtocolList: Auto
> ObjCBlockIndentWidth: 2
> ObjCSpaceAfterProperty: false
> ObjCSpaceBeforeProtocolList: true
> PenaltyBreakAssignment: 2
> PenaltyBreakBeforeFirstCallParameter: 19
> PenaltyBreakComment: 300
> PenaltyBreakFirstLessLess: 120
> PenaltyBreakString: 1000
> PenaltyBreakTemplateDeclaration: 10
> PenaltyExcessCharacter: 100
> PenaltyReturnTypeOnItsOwn

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

2020-03-14 Thread Adam Feuer

David, Maciej, Peter,

Thanks for your help!

IndentPPDirectives: PPDIS_AfterHash works. The actual syntax for the
.clang-format file is this:

IndentPPDirectives: AfterHash

That makes things a lot better. There are a bunch of inconsistent macro
indents under sched/ though— many macros indent ok, but there are a bunch
that don't. Not sure what to do about that... are they really inconsistent?
If so maybe we make a small PR that fixes the inconsistent indents?

What seems to be next:

   - alignment of successive expressions

   reltime.tv_nsec += NSEC_PER_SEC;
> -  reltime.tv_sec  -= 1;
> +  reltime.tv_sec -= 1;
>

   - alignment of comment blocks — to make sure they line up with the next
   comment line in the block

For instance:

-  /* The resulting set is the intersection of the current set and
> +/* The resulting set is the intersection of the current set
> and
> * the complement of the signal set pointed to by _set.
> */
>

   - evaluating inconsistencies in the alignment style... some expressions
   and declarations are aligned, others are not... I need to consult the style
   guide to see what it says.


I'm using clang-format-9. Here's the command lines I'm running to generate
and look at the changes (in the nutt/ dir):

$ find ./sched/ -iname "*.h" -or -iname "*.c" | xargs clang-format-9 -i
-style=file
$ git diff
$ # change .clang-format
$ git stash; git stash drop


Here's my .clang format file as of now:

---
Language:Cpp
AccessModifierOffset: -2
AlignAfterOpenBracket: Align
AlignConsecutiveMacros: true
AlignConsecutiveAssignments: true
AlignConsecutiveDeclarations: true
AlignEscapedNewlines: DontAlign
AlignOperands:   true
AlignTrailingComments: true
AllowAllArgumentsOnNextLine: true
AllowAllConstructorInitializersOnNextLine: true
AllowAllParametersOfDeclarationOnNextLine: true
AllowShortBlocksOnASingleLine: false
AllowShortCaseLabelsOnASingleLine: false
AllowShortFunctionsOnASingleLine: All
AllowShortLambdasOnASingleLine: All
AllowShortIfStatementsOnASingleLine: Never
AllowShortLoopsOnASingleLine: false
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakAfterReturnType: None
AlwaysBreakBeforeMultilineStrings: false
AlwaysBreakTemplateDeclarations: MultiLine
BinPackArguments: true
BinPackParameters: true
BraceWrapping:
  AfterCaseLabel:  false
  AfterClass:  false
  AfterControlStatement: true
  AfterEnum:   true
  AfterFunction:   true
  AfterNamespace:  false
  AfterObjCDeclaration: false
  AfterStruct: true
  AfterUnion:  true
  AfterExternBlock: false
  BeforeCatch: false
  BeforeElse:  true
  IndentBraces:true
  SplitEmptyFunction: true
  SplitEmptyRecord: true
  SplitEmptyNamespace: true
BreakBeforeBinaryOperators: None
BreakBeforeBraces: Custom
BreakBeforeInheritanceComma: false
BreakInheritanceList: BeforeColon
BreakBeforeTernaryOperators: true
BreakConstructorInitializersBeforeComma: false
BreakConstructorInitializers: BeforeColon
BreakAfterJavaFieldAnnotations: false
BreakStringLiterals: true
ColumnLimit: 0
CommentPragmas:  '^ IWYU pragma:'
CompactNamespaces: false
ConstructorInitializerAllOnOneLineOrOnePerLine: false
ConstructorInitializerIndentWidth: 4
ContinuationIndentWidth: 0
Cpp11BracedListStyle: false
DerivePointerAlignment: false
DisableFormat:   false
ExperimentalAutoDetectBinPacking: false
FixNamespaceComments: false
ForEachMacros:
  - foreach
  - Q_FOREACH
  - BOOST_FOREACH
IncludeBlocks:   Preserve
IncludeCategories:
  - Regex:   '^"(llvm|llvm-c|clang|clang-c)/'
Priority:2
  - Regex:   '^(<|"(gtest|gmock|isl|json)/)'
Priority:3
  - Regex:   '.*'
Priority:1
IncludeIsMainRegex: '(Test)?$'
IndentCaseLabels: true
IndentPPDirectives: AfterHash
IndentWidth: 2
IndentWrappedFunctionNames: false
JavaScriptQuotes: Leave
JavaScriptWrapImports: true
KeepEmptyLinesAtTheStartOfBlocks: true
MacroBlockBegin: ''
MacroBlockEnd:   ''
MaxEmptyLinesToKeep: 1
NamespaceIndentation: None
ObjCBinPackProtocolList: Auto
ObjCBlockIndentWidth: 2
ObjCSpaceAfterProperty: false
ObjCSpaceBeforeProtocolList: true
PenaltyBreakAssignment: 2
PenaltyBreakBeforeFirstCallParameter: 19
PenaltyBreakComment: 300
PenaltyBreakFirstLessLess: 120
PenaltyBreakString: 1000
PenaltyBreakTemplateDeclaration: 10
PenaltyExcessCharacter: 100
PenaltyReturnTypeOnItsOwnLine: 60
PointerAlignment: Right
ReflowComments:  false
SortIncludes:false
SortUsingDeclarations: true
SpaceAfterCStyleCast: false
SpaceAfterLogicalNot: false
SpaceAfterTemplateKeyword: true
SpaceBeforeAssignmentOperators: true
SpaceBeforeCpp11BracedList: false
SpaceBeforeCtorInitializerColon: true
SpaceBeforeInheritanceColon: true
SpaceBeforeParens: ControlStatements
SpaceBeforeRangeBasedForLoopColon: true
SpaceInEmptyParentheses: false
SpacesBeforeTrailingComments: 1
SpacesInAngles:  false
SpacesInContainerLiterals: true
SpacesInCStyleCastParentheses: false
SpacesInParentheses: false
SpacesIn

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

RE: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

Re: Nuttx Code Formatter Progress [Was RE: Should we relax precheck a little bit?]

15 matches

Site Navigation

Mail list logo

Footer information