ed/gencpp
1
0
Fork 0
mirror of https://github.com/Ed94/gencpp.git synced 2024-09-20 11:27:32 -07:00
Code Issues Packages Projects Releases Wiki Activity
4997cb5878
gencpp/scripts/.clang-format

172 lines
3.7 KiB
Plaintext
Raw Normal View History

Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
# Format Style Options - Created with Clang Power Tools
---
AccessModifierOffset: -4
AlignAfterOpenBracket: BlockIndent
bootstrap and singleheader compile and generate.
2023-07-29 09:25:38 -07:00
AlignArrayOfStructures: Left
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
AlignConsecutiveAssignments:
Enabled: true
Heavy refactor.. Isolating large macros to their own directory (components/temp). - Plan is to remove them soon with proper generation. Added additional component files, separating the old data_structures header for a set of ast headers. Header_end also had its inlines extracted out. Necessary to complete the macro isolation. ZPL parser dependencies were removed from the core library along with builder, its now generated in bootstrap as pare of making a gen_builder set of files. Singleheader will be changed in next few commits to reflect this as well (By making builder deps and components a conditional option). Tests are most likely all broken for now.
2023-08-03 08:01:43 -07:00
AcrossEmptyLines: true
AcrossComments: false
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
AlignCompound: true
PadOperators: true
Heavy refactor.. Isolating large macros to their own directory (components/temp). - Plan is to remove them soon with proper generation. Added additional component files, separating the old data_structures header for a set of ast headers. Header_end also had its inlines extracted out. Necessary to complete the macro isolation. ZPL parser dependencies were removed from the core library along with builder, its now generated in bootstrap as pare of making a gen_builder set of files. Singleheader will be changed in next few commits to reflect this as well (By making builder deps and components a conditional option). Tests are most likely all broken for now.
2023-08-03 08:01:43 -07:00
AlignConsecutiveBitFields:
Enabled: true
AcrossEmptyLines: true
AcrossComments: false
AlignConsecutiveDeclarations:
Enabled: true
AcrossEmptyLines: false
AcrossComments: false
Started to generate the enums from csv (ECode, EOperator, ESpecifier). - Changed the zpl csv parser to only accept hex values with 0x perfix. it was messing with the add term. - Small changes to the clang format config.
2023-07-26 11:21:20 -07:00
AlignConsecutiveMacros:
Enabled: true
AcrossEmptyLines: true
Heavy refactor.. Isolating large macros to their own directory (components/temp). - Plan is to remove them soon with proper generation. Added additional component files, separating the old data_structures header for a set of ast headers. Header_end also had its inlines extracted out. Necessary to complete the macro isolation. ZPL parser dependencies were removed from the core library along with builder, its now generated in bootstrap as pare of making a gen_builder set of files. Singleheader will be changed in next few commits to reflect this as well (By making builder deps and components a conditional option). Tests are most likely all broken for now.
2023-08-03 08:01:43 -07:00
AcrossComments: false
Started to generate the enums from csv (ECode, EOperator, ESpecifier). - Changed the zpl csv parser to only accept hex values with 0x perfix. it was messing with the add term. - Small changes to the clang format config.
2023-07-26 11:21:20 -07:00
AlignEscapedNewlines: Left
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
AlignOperands: DontAlign
AlignTrailingComments: true
AllowAllArgumentsOnNextLine: false
AllowAllConstructorInitializersOnNextLine: false
AllowAllParametersOfDeclarationOnNextLine: false
AllowShortBlocksOnASingleLine: Never
AllowShortCaseLabelsOnASingleLine: false
AllowShortLambdasOnASingleLine: None
AllowShortEnumsOnASingleLine: false
AllowShortFunctionsOnASingleLine: None
AllowShortIfStatementsOnASingleLine: Never
AllowShortLoopsOnASingleLine: false
AlwaysBreakAfterReturnType: None
AlwaysBreakBeforeMultilineStrings: true
AlwaysBreakTemplateDeclarations: Yes
Fixes towards parsing (getting to line 12575 now of the singleheader.
2023-08-02 09:39:35 -07:00
BinPackArguments: false
BinPackParameters: false
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
BitFieldColonSpacing: Both
Started to generate the enums from csv (ECode, EOperator, ESpecifier). - Changed the zpl csv parser to only accept hex values with 0x perfix. it was messing with the add term. - Small changes to the clang format config.
2023-07-26 11:21:20 -07:00
BraceWrapping:
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
AfterCaseLabel: false
AfterClass: false
AfterControlStatement: false
AfterEnum: false
AfterFunction: false
AfterNamespace: false
AfterObjCDeclaration: false
AfterStruct: false
AfterUnion: false
AfterExternBlock: false
BeforeCatch: false
BeforeElse: false
IndentBraces: false
SplitEmptyFunction: false
SplitEmptyRecord: false
SplitEmptyNamespace: false
BeforeLambdaBody: false
BeforeWhile: false
bootstrap and singleheader compile and generate.
2023-07-29 09:25:38 -07:00
BreakAfterAttributes: Always
Heavy refactor.. Isolating large macros to their own directory (components/temp). - Plan is to remove them soon with proper generation. Added additional component files, separating the old data_structures header for a set of ast headers. Header_end also had its inlines extracted out. Necessary to complete the macro isolation. ZPL parser dependencies were removed from the core library along with builder, its now generated in bootstrap as pare of making a gen_builder set of files. Singleheader will be changed in next few commits to reflect this as well (By making builder deps and components a conditional option). Tests are most likely all broken for now.
2023-08-03 08:01:43 -07:00
BreakArrays: true
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
# BreakBeforeInlineASMColon: OnlyMultiline
BreakBeforeBinaryOperators: NonAssignment
BreakBeforeBraces: Allman
BreakBeforeInheritanceComma: true
BreakInheritanceList: BeforeComma
BreakBeforeConceptDeclarations: true
BreakBeforeTernaryOperators: true
BreakConstructorInitializers: BeforeComma
BreakStringLiterals: true
Heavy refactor.. Isolating large macros to their own directory (components/temp). - Plan is to remove them soon with proper generation. Added additional component files, separating the old data_structures header for a set of ast headers. Header_end also had its inlines extracted out. Necessary to complete the macro isolation. ZPL parser dependencies were removed from the core library along with builder, its now generated in bootstrap as pare of making a gen_builder set of files. Singleheader will be changed in next few commits to reflect this as well (By making builder deps and components a conditional option). Tests are most likely all broken for now.
2023-08-03 08:01:43 -07:00
ColumnLimit: 160
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
CompactNamespaces: true
ConstructorInitializerAllOnOneLineOrOnePerLine: true
ConstructorInitializerIndentWidth : 4
ECode, ESpecifier, and ETokType are now all generated. There is a redundant pattern for generating all three (as expected). I'll use it to define a general way of doing this sort of behavior.
2023-07-26 23:51:36 -07:00
ContinuationIndentWidth: 0
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
Cpp11BracedListStyle: false
DeriveLineEnding: true
ExperimentalAutoDetectBinPacking: false
FixNamespaceComments: true
IncludeBlocks: Preserve
Started to generate the enums from csv (ECode, EOperator, ESpecifier). - Changed the zpl csv parser to only accept hex values with 0x perfix. it was messing with the add term. - Small changes to the clang format config.
2023-07-26 11:21:20 -07:00
IndentCaseBlocks: false
Fixes towards parsing (getting to line 12575 now of the singleheader.
2023-08-02 09:39:35 -07:00
IndentCaseLabels: true
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
IndentExternBlock: AfterExternBlock
bootstrap and singleheader compile and generate.
2023-07-29 09:25:38 -07:00
IndentGotoLabels: true
Fixes to serialization, reduced Define_CodeType macro Now the execution code is generated in bootstrap/singleheader gen.
2023-08-06 14:19:57 -07:00
IndentPPDirectives: None
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
IndentRequires: true
IndentWidth: 4
Fixes towards parsing (getting to line 12575 now of the singleheader.
2023-08-02 09:39:35 -07:00
IndentWrappedFunctionNames: true
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
# InsertNewlineAtEOF: true
Progress toward preprocessor parsing, lexing works, parsing does not.
2023-07-30 15:55:57 -07:00
# InsertTrailingCommas: Wrapped
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
LambdaBodyIndentation: OuterScope
Language: Cpp
MaxEmptyLinesToKeep: 4
NamespaceIndentation: All
PointerAlignment: Left
QualifierAlignment: Leave
ReferenceAlignment: Left
ReflowComments: true
# RequiresExpressionIndentation: OuterScope
SeparateDefinitionBlocks: Always
ShortNamespaceLines: 40
bootstrap and singleheader compile and generate.
2023-07-29 09:25:38 -07:00
SortIncludes: false
Heavy refactor.. Isolating large macros to their own directory (components/temp). - Plan is to remove them soon with proper generation. Added additional component files, separating the old data_structures header for a set of ast headers. Header_end also had its inlines extracted out. Necessary to complete the macro isolation. ZPL parser dependencies were removed from the core library along with builder, its now generated in bootstrap as pare of making a gen_builder set of files. Singleheader will be changed in next few commits to reflect this as well (By making builder deps and components a conditional option). Tests are most likely all broken for now.
2023-08-03 08:01:43 -07:00
SortUsingDeclarations: false
Progress towards bootstrap/singleheader generation I will most likely need to refactor some of the components & dependencies files to get the desired gneration implementation the way I want. Specficially I want to be able to eliminate macros I'm using for enums and common patterns for implmeentation of the data structures. When it comes to the cpp files, I may leave those alone as the macros largely help ith readability. Replacing those macros is expensive and most likely not worth it. The macros under consideration with replacing using the library bootstrap are: * Define_Types * Define_Operators * Define_Specifiers * GEN_Define_Attribute_Tokens * Define_CodeType * Using_Code * Define_TokType * def_constant_spec ? * Helper Macros for def_**_body functions ? * AST unallowed types case macros? (The last three I'm unsure about as they work fine, and neeeding the debugger steps there is a rare scenario...) The enums could be manually generated and have its fields derived from a CSV (which is what genc is currently doing). This would allow the user to specify custom attribute macros as well with greater ease. I may maually inline ProcessModuleFlags, as its not even necessary as any specific symbol with a module flag will only use the export value. Import is only used on modules themselves (from what I can tell). The Parser::lex function could be offloaded to its own file in case the user wants to swap the entire thing out. (Most likely may want to for various purposes) The problem with extracting any definitions out of a component file currently is that will lead to splintering that componnet to multiple other components. This is necessary as the proper scanner is not implemented yet (only a reduimentary scan_file proc is made so far).
2023-07-24 19:19:21 -07:00
SpaceAfterCStyleCast: false
SpaceAfterLogicalNot: true
SpaceAfterTemplateKeyword: false
SpaceAroundPointerQualifiers: Default
SpaceBeforeAssignmentOperators: true
SpaceBeforeCaseColon: true
SpaceBeforeCpp11BracedList: true
SpaceBeforeCtorInitializerColon: true
SpaceBeforeInheritanceColon: true
SpaceBeforeParens: ControlStatementsExceptControlMacros
SpaceBeforeRangeBasedForLoopColon: true
SpaceBeforeSquareBrackets: false
SpacesBeforeTrailingComments: 4
SpaceInEmptyBlock: true
SpaceInEmptyParentheses: false
SpacesInAngles: true
SpacesInCStyleCastParentheses: true
SpacesInConditionalStatement: true
SpacesInContainerLiterals: true
SpacesInLineCommentPrefix:
Minimum: 1
Maximum: 20
SpacesInParentheses: true
SpacesInSquareBrackets: true
Standard: c++17
TabWidth: 4
UseTab: ForIndentation
...
Reference in New Issue Copy Permalink