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>
