Sysprogs forums › Forums › VisualGDB › clang-format issues
Tagged: A9playofficialmy
- This topic has 7 replies, 3 voices, and was last updated 1 year, 9 months ago by tajen.
-
AuthorPosts
-
April 26, 2021 at 09:12 #30411mttjcksnParticipant
Hi there,
I’m using VisualGDB 5.5 with Microsoft Visual Studio Community 2019 Version 16.9.3, and getting unpredictable results with clang-format.
All project configurations are set to Default Clang for both intellisense and code formatting. I have specified a .clang-format file that works with LLVM clang-format v12 on the command line, but I get all sorts of issues with it in visual studio.
For example, formatting this line:
ALIGN_32BYTES(volatile uint32_t buffer[____EXAMPLE_MACRO_1 * ____EXAMPLE_MACRO_2 * ____EXAMPLE_MACRO_3] __attribute__((section(".bufferSection"))));
using visualGDB clang-format:
ALIGN_32BYTES(
volatile uint32_t
buffer[____EXAMPLE_MACRO_1 * ____EXAMPLE_MACRO_2 * ____EXAMPLE_MACRO_3]
__attribute__((section(".bufferSection"))));
but using llvm clang-format v12:
ALIGN_32BYTES(volatile uint32_t buffer[____EXAMPLE_MACRO_1 * ____EXAMPLE_MACRO_2 * ____EXAMPLE_MACRO_3] __attribute__((section(".bufferSection"))));
Here is an example clang-format file that gives this result:
<hr />
Language: Cpp
# BasedOnStyle: Microsoft
AccessModifierOffset: -2
AlignAfterOpenBracket: Align
AlignConsecutiveMacros: true
AlignConsecutiveAssignments: true
AlignConsecutiveDeclarations: false
AlignEscapedNewlines: Right
AlignOperands: true
AlignTrailingComments: true
# AllowAllArgumentsOnNextLine: true
# AllowAllConstructorInitializersOnNextLine: true
AllowAllParametersOfDeclarationOnNextLine: true
# AllowShortBlocksOnASingleLine: Never
# AllowShortCaseLabelsOnASingleLine: false
# AllowShortFunctionsOnASingleLine: None
# AllowShortLambdasOnASingleLine: All
# AllowShortIfStatementsOnASingleLine: Never
# AllowShortLoopsOnASingleLine: false
AlwaysBreakAfterDefinitionReturnType: None
AlwaysBreakAfterReturnType: None
AlwaysBreakBeforeMultilineStrings: false
AlwaysBreakTemplateDeclarations: MultiLine
BinPackArguments: true
BinPackParameters: true
BraceWrapping:
# AfterCaseLabel: false
AfterClass: true
AfterControlStatement: true
AfterEnum: true
AfterFunction: true
AfterNamespace: true
AfterObjCDeclaration: true
AfterStruct: true
AfterUnion: false
AfterExternBlock: true
BeforeCatch: true
BeforeElse: true
IndentBraces: false
SplitEmptyFunction: true
SplitEmptyRecord: true
SplitEmptyNamespace: true
BreakBeforeBinaryOperators: None
BreakBeforeBraces: Allman
ColumnLimit: '0'
...
In this specific example it looks as if the visualGDB clang-format is ignoring
ColumnLimit: '0'.
There are various other differences between the outputs, such as how array initialisers are formatted, and where line breaks are placed in expressions.I would ideally use the visualGDB clang format, because I have issues with the visual studio intellisense when using visualGDB, but so far have not been able to make a usable .clang-format file that gives the same results in llvm clang-format and visualGDB clang-format.
Any ideas??
Many thanks, Matt
April 26, 2021 at 14:02 #30412supportKeymasterHi,
The VisualGDB’s IntelliSense engine internally uses Clang 6.0. Hence if you are relying on a setting that was added in a newer version, it will not work. We will update the Clang version used by our engine in one of the next VisualGDB releases.
April 27, 2021 at 01:11 #30413mttjcksnParticipantThanks for the reply. I just checked every setting in the example I gave above against the version 6 docs here:
https://releases.llvm.org/6.0.0/tools/clang/docs/ClangFormatStyleOptions.html
The only one not present was AlignConsecutiveMacros, so I removed it. Unfortunately the outcome is still the same. I have double checked that the file is using this clang-format file by clicking the formatting style button in the editor.
Is there anything else I am missing?
Is there a list of clang version differences, or any kind of tool to help me work out what the differences are so I can convert a modern clang format to use the old version 6 format?
Is it possible to disable VisualGDB’s clang-format but keep VisualGDB’s intellisense?
Many thanks
- This reply was modified 3 years, 8 months ago by mttjcksn.
April 27, 2021 at 01:55 #30415supportKeymasterNo problem, we can walk you through the various settings and try to suggest a few workarounds, however we would kindly ask you renew your technical support first, as it has expired a while ago.
April 27, 2021 at 04:34 #30417mttjcksnParticipantThanks. I have had some luck using
BasedOnStyle: LLVM
and adding a small number of rules on top of that. Perhaps having a large clang-format file causes more problems than it’s worth!March 2, 2023 at 05:20 #33913tajenParticipantDoes that mean, that even though VS2019 uses clang-format 12.0.0, VisualGDB uses clang-format 6?
And has that been updated in the newest version/what is the current version in VisualGDB?
March 3, 2023 at 08:45 #33939supportKeymasterHi,
Visual Studio runs Clang as an external tool and applies the formatting instructions reported by it. This allows quickly switching between Clang versions, but has a few drawbacks, particularly when reformatting just one statement (e.g. when pressing ‘}’), and computing indentation for the new line.
VisualGDB uses a different approach – clang is integrated into our IntelliSense engine, so it continuously keeps a model of the current source file, and can apply more fine-tuned formats (and provide a GUI editor for formatting settings). The downside here is that switching to a newer clang requires updating our entire IntelliSense engine, and running extensive tests to ensure it won’t break any existing functionality.
We are currently finishing our work with the new tracing engine, that is being first released with VisualKernel (kernel traces generate huge volumes of data, so we use it to make sure the tracing engine is blazingly fast even under most heavy loads); updating the Clang engine to the latest LLVM/clang version is scheduled right after it.
March 3, 2023 at 11:27 #33943tajenParticipantThanks for the reply. It really helps to understand why thing are as they are.
We will handle the limitation of clang 6 until it is updated.
-
AuthorPosts
- You must be logged in to reply to this topic.