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 <a...@starcat.io> 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 <david.sidr...@nscdg.com> > 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 <a...@starcat.io> 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 >> >> <repeat> >> >> >> >> 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: 1000000 >> 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 >> SpacesInSquareBrackets: false >> Standard: Cpp03 >> StatementMacros: >> - Q_UNUSED >> - QT_REQUIRE_VERSION >> TabWidth: 8 >> UseTab: Never >> ... >> >> >> >> >> >> >> >> >> >> On Sat, Mar 14, 2020 at 1:29 AM David Sidrane <david.sidr...@nscdg.com> >> wrote: >> >> Hi Adam and Maciej, >> >> Thank you for spending you time on this. It will be a huge win for >> everyone! >> >> The way I have been looking at this is like in transfer-function with an >> offset. Once we can get a tools that will take X and make into X" that has >> well known malformations. We just fix the malformations. So once you feel >> have something that is close, let's evaluate it and see what the "last >> mile" >> looks like. >> >> David >> >> -----Original Message----- >> From: Adam Feuer [mailto:a...@starcat.io] >> Sent: Friday, March 13, 2020 7:08 PM >> To: dev@nuttx.apache.org >> Subject: Re: Should we relax precheck a little bit? >> >> Maciej, >> >> Thank you! I didn't know about the IndentPPDirectives option! I will try >> it! :) >> >> -adam >> >> On Fri, Mar 13, 2020 at 5:16 PM Maciej Wójcik <w8j...@gmail.com> wrote: >> >> > Are you sure that clang-format cannot indent macros? What about >> > >> > IndentPPDirectives: PPDIS_AfterHash >> > >> > It also treats the outmost macro in headers in a special way. >> > >> > On Sat, 14 Mar 2020, 01:03 Adam Feuer, <a...@starcat.io> wrote: >> > >> > > David, >> > > >> > > Re: whatstyle, I ran it overnight on the c files in sched/ and came up >> > with >> > > a clang-format that does somewhat ok. Thanks for pointing that program >> > out. >> > > >> > > By looking at the output of the diff, I learned a lot about how hard >> it >> > is >> > > to manually format programs. :) >> > > >> > > Anyway, the biggest problem with clang-format seems to be the way it >> > > handles C-macros. In NuttX, they are often indented like this: >> > > >> > > #ifdef ... >> > > # define ... >> > > # ifdef ... >> > > # define >> > > # endif >> > > #endif >> > > >> > > Peter Van Der Perk also mentioned this. There's no stock way to make >> > > clang-format do that. Maybe a post-processing script that only looked >> at >> > > these macros would work. Or a contribution to clang-format. I'll think >> > > about it some more. >> > > >> > > -adam >> > > >> > > On Sun, Mar 8, 2020 at 3:40 AM David Sidrane <david.sidr...@nscdg.com >> > >> > > wrote: >> > > >> > > > Hi Adam, >> > > > >> > > > Have a look at https://github.com/mikr/whatstyle >> > > > >> > > > I got furthest with clang-format and it. It may be we get a 95% of >> the >> > > way >> > > > there with it and we can add a backend secondary scripts. >> > > > >> > > > I was unable to convince Greg to create a master template so my >> > approach >> > > > was >> > > > to combine all the files and run it on the set so it would get all >> the >> > > > constructs at once. >> > > > >> > > > David >> > > > >> > > >> > > -- >> > > Adam Feuer <a...@starcat.io> >> > > >> > >> >> >> -- >> Adam Feuer <a...@starcat.io> >> >> >> >> -- >> >> Adam Feuer <a...@starcat.io> >> >> >> >> -- >> >> Adam Feuer <a...@starcat.io> >> > > > -- > Adam Feuer <a...@starcat.io> > -- Adam Feuer <a...@starcat.io>
