clang-format breaks lint annotations - c++

We use lint in our codebase at work for C/C++, I'm trying to start integrating clang-format in my workflow as well.
Unfortunately, lint occasionally requires annotations to ignore a specific check, either of the format:
/*lint -[annotation] */
or
//lint -[annotation]
Specifically, if there's a space between the opening token for the comment and 'lint', it doesn't recognize it as an annotation directive. Unfortunately, the default settings I have for clang-format see that as an error and helpfully insert the space.
Is there any way to get clang-format to recognize comments matching that pattern and leave them alone? Right now I'm using 3.4, but could upgrade if needed.

Clang-format has a `CommentPragmas' option that is
A regular expression that describes comments with special meaning, which should not be split into lines or otherwise changed.
When I put the following line in my .clang-format file, my Lint comments remain untouched.
CommentPragmas: '^lint'
Other comments that still have "lint" in them, but are not Lint comments still get formatted.

You can disable clang-format for that section of your file by using:
int formatted_code;
// clang-format off
void unformatted_code ;
// clang-format on
void formatted_code_again;
See the Disabling formating on a piece of code section.

Related

How to set up clang-format comment pragmas so multiline doxygen comments don't get touched?

I am trying to introduce clang-format to a couple of our projects at work (C and C++), but I am having trouble getting it to format multi-line Doxygen comments the way I want.
All comments have the same format:
/*! #brief Some text
*
* Some more text
*
* #verbatim
*
* A very long line of text that exceeds the clang-format column width but should not be touched
*
* #endverbatim
*/
I want clang-format to leave the verbatim blocks alone and not reflow them. I am using clang-format-6.0
Turning ReflowComments off is not an option as non-doxygen comments must be taken care of by clang-format
I have tried various regular expressions in the CommentPragmas config item but to no avail:
#verbatim(.*\n)*.*#endverbatim to treat the entire verbatim block as a comment pragma. This is the ideal situation, as any other part of the Doxygen comment I do not mind being broken into multiple lines.
#brief(.*\n)+ to match the entire comment block as the pragma. I've also tried this with an arbitrary token at the end of the comment to act as an explicit end-of-block marker. This isn't ideal as it doesn't force the non-verbatim part of the comment to conform, but is a compromise I'm willing to live with if I have to.
Various other regexes I've seen in other discussions, adapted to fit our Doxygen markup.
All I've managed to get it to do so far is to leave the first line of the multi-line comment alone, if it happens to exceed the column limit. However, any following long line is still broken up.
The only other tool I have left in my box is to use // clang-format off and // clang-format on around these comments but again I'd like to avoid it if I can because:
a) it'll be quite tedious to add them throughout the code base
b) I'll have to surround the entire comments with these, rather than just the verbatim blocks (I haven't figured out if you can disable it just for a portion of a multi-line comment - I've only managed to get it working for an entire one, and even if that was possible the clang-format directives would end up in the generated Doxygen docs which is unacceptable)
c) I don't really like the way it looks in code.
Any help is appreciated. Thanks.
Ran into this issue also, and the only work around found was to use clang-format on/off.
clang-format re flowing comments tends to:
break #page, #section, etc titles, and links generated from them (in rare cases).
break #startuml blocks, which have a specific syntax.
break #verbatim blocks.
See an example of usage in MySQL:
https://github.com/mysql/mysql-server/blob/8.0/storage/perfschema/pfs.cc
Update:
Filed a feature request on clang-format itself:
https://bugs.llvm.org/show_bug.cgi?id=44486

clang-format: disable formatting for macros?

I am using clang-format as the auto-formatting tool for my codebase. But some of its features are bugging me.
For instance, I don't want it to format my macro definitions, since most of the time, it's more clear to just formatting them manually. But I don't know how to disable it in clang-format.
Another minor issue is pointer alignment. Sometimes, it's clear to make it aligned left, sometimes it's right. So I'd rather do it by hand. But disable it from clang-format seems impossible?
Any help on these issues?
You can wrap your macros in
// clang-format off
#define ... \
...
// clang-format on
To escape manually editing of each file you can use the regex
search: ^([ \t]*#[ \t]*define[ \t]+.+?\\\r?\n(?:.*?\\\r?\n)*.*?\r?\n)
replace: // clang-format off\r\n$1// clang-format on\r\n
for instance, in Notepad++, Ctrl+Shift+F - "Find in Files - "Replace in Files".
To date (up to v11) there is no way to disable pointer alignment. You can either set the style, or derive the style (clang-format will analyze a file for the most common alignment of & and * and will use it).

How to reset code formatting with Uncrustify

I am using Uncrustify to formatting my C++ code and I am making some experiments with infinite list of settings.
Because of some bad settings my code now has a lot of new line that split statement in more lines (mostly due to a short line width).
I would like to reformat the code in order to have one statement per line and reformat it in another way.
How can I do it?
There is no undo function in Uncrustify and if your SCM can not help you, you are unfortunately out of luck.
Regarding to the newlines, which seem to cause the most problems for you, you could try to remove and reapply them with the 'nl_remove_extra_newlines' option (see a short discussion about it in the uncrustify issue #994) in combination with other options that are influencing newlines.

clang-format Overriding multi-line comments for WebKit style

I am trying to use clang-format to clean up code in my repository. We are using the WebKit style as the basis for formatting, however we also want to make sure that multi line comments are formatted correctly.
From my understanding it is possible override the formatting rules of given style by define the .clang-format file as such:
BasedOnStyle: WebKit
AlignTrailingComments: true
This way clang-format should align the trailing comments.
Given the input file:
/**
* This is a multi-line comment
*/
void function() {
/**
* This is comment inside the function
*/
}
My expectation is the following output
/**
* This is a multi-line comment
*/
void function()
{
/**
* This is comment inside the function
*/
}
However what I get is:
/**
* This is a multi-line comment
*/
void function()
{
/**
* This is comment inside the function
*/
}
I've tried dumping out the formatting options of Webkit into a .clang-format file and changing the AlignTrailingComments from false to true. This doesn't make and difference either.
Is there some option in the Webkit style that is interfering with the AlignTrailingComments option?
AlignTrailingComments aligns comments trailing code in consecutive lines:
int short; // short
int longlonglong; // long
The real issue here is the pre-defined WebKit style setting ColumnLimit: 0. This somehow disables the indentation of non-first-line-part of multi-line comments. (And this doesn't seem to be documented anywhere - I think it's a bug.)
One workaround would be to set the column limit to something reasonable, like ColumnLimit: 80 or possibly ColumnLimit: 120. Possibly you could do this once, and then switch back to your usual ColumnLimit: 0 - but setting the column limit once will likely change formatting on many code lines, which will not be restored when you change the column limit back to zero, so probably not what you want.
AlignTrailingComments does not relate to this at all. As another answer explains, this is for aligning the trailing comments at the end of code lines. See the documentation for more details.
I don't believe CommentPragmas will help either. I'm pretty sure this only prevents clang-format from adding line breaks to those comments, but does not prevent indentation changes. (And this is not really documented either.) Anyway, what is needed here is adjusting the indentation, not leaving it alone, so CommentPragmas almost seems like the opposite of what is needed.
A possible workaround: use CommentPragmas with a regex to mark those comments as untouchable.

Easily comment (C++) code in vim

I have looked at the following question:
How to comment out a block of Python code in Vim
But that does not seem to work for me. How do I comment code easily without resorting to plugins/scripts?
Use ctrl-V to do a block selection and then hit I followed by //[ESC].
Alternatively, use shift-V to do a line-based select and then type :s:^://[Enter]. The latter part could easily go into a mapping. eg:
:vmap // :s:^://<CR>
Then you just shift-V, select the range, and type // (or whatever you bind it to).
You can add this to your .vimrc file
map <C-c> :s/^/\/\//<Enter>
Then when you need to comment a section just select all lines (Shift-V + movement) and then press CtrlC.
To un-comment you can define in a similar way
map <C-u> :s/^\/\///<Enter>
that removes a // at begin of line from the selected range when pressing CtrlU.
You can use the NERD commenter plugin for vim, which has support for a whole bunch of languages (I'm sure C++ is one of them). With this installed, to comment/uncomment any line, use <Leader>ci. To do the same for a block of text, select text by entering the visual mode and use the same command as above.
There are other features in this such as comment n lines by supplying a count before the command, yank before comment with <Leader>cy, comment to end of line with <Leader>c$, and many others, which you can read about in the link. I've found this plugin to be extremely useful and is one of my 'must have' plugins.
There's always #ifdef CHECK_THIS_LATER ... #endif which has the advantage of not causing problems with nested C-style comments (if you use them) and is easy to find and either uncomment or remove completely later.