I'm working on a C++ project that has some large sections of code that are autogenerated, and I don't want to be linted. Is there something akin to the //NOLINT comment that can be applied to multiple lines? Like the following:
// BEGINNOLINT
bad-code;
// ENDNOLINT
All I could find online was a suggestion that this should be implemented. Is there any way to avoid having to write // NOLINT on the end of every single line?
clang-tidy 14 introduced this feature:
// NOLINTBEGIN
...
// NOLINTEND
Note, if you want to disable a specific warning, the end-comment must match the begin-comment:
// NOLINTBEGIN(check-name)
...
// NOLINTEND(check-name)
Unfortunately there is no direct way to do this, clang-tidy only supports //NOLINT and //NOLINTNEXTLINE.
I don't know how much control you have about that code generation...you could generate it in one line, that could help you a lot as c++ doesn't care about whitespace.
A crude but effective solution is to use a text-manipulation tool like sed:
$ sed -i -re '/^\/\/BEGIN_NOLINT/,/^\/\/END_NOLINT/{s/$/\/\/NOLINT/}' *.cpp
This would add //NOLINT at the end of every line between //BEGIN_NOLINT and //END_NOLINT comments (which can be probably generated).
You can also run clang-tidy with parameter
-line-filter='[{"name":"test.cpp","lines":[[1,10],[12,100]]}]'
Line 11 will be skipped in this example. This is however difficult to maintain as you need to update the filter every time you add/remove lines in the file. Maybe it would be a good idea to generate code into separate files if possible.
Im sure that, when Im applying //NOLINTNEXTLINE on MACRO, so the entire MARCO is skiped. So try to implement //NOLINTNEXTLINE to your class or function
Related
i am reading swift from apple docs and learning about statements. but couldnot find any information about the Line Control Statements.
According to the docs
A line control statement is used to specify a line number and filename
that can be different from the line number and filename of the source
code being compiled. Use a line control statement to change the source
code location used by Swift for diagnostic and debugging purposes.
A line control statement has the following forms:
#sourceLocation(file: filename, line: line number)
#sourceLocation()
My question is when should i use it? The docs lags an example about the topic.Any links or some hints would be helpful.
This isn't the sort of thing you'd ever need as a beginner, and you could probably go through an entire career without using it. It seems to be meant for use in tools that generate source code. See the comments in the original feature proposal for the complete story.
TL/DR: Don't worry about it, you'll never need it.
After googling a bit it seems there is no multi-line comment support in Erlang, is this really the case?
And if so, why?
I know some editors support commenting out regions (adding % first on every line of the region) but i don't really want to pick editor based on this.
It's simple. Use preprocessor:
-ifdef(comment).
Something to comment
You can add text or
function(Declaration) ->
...
Which will removed from file
-endif.
There are no multi-line comments in Erlang.
In general, I haven't found this to be a big deal: I use templates for gen_server and supervisor and a general template for other modules, and all of these include the boilerplate top doc blocks. I get some template support from my editor (Emacs) but you could be editor-agnostic and just write some templates and copy them to any new modules you want.
The biggest use of multi-line comments other than documentation is to comment-out a big chunk of code. Since your Erlang code should generally be small functions, you can just comment out the function call, which is a one-line comment.
I want to have two lexers in one project, and I don't want to run into problems with having multiple yylex functions in the build. Can I make lex output with a different prefix?
You can use the -Pprefix parameter for flex in your makefile. Using flex -Pfoo you would effectively prefix all yy generated functions. Have a look at the manual page for further details.
flex lets you do that. Just define the YY_DECL macro. Dunno about actual Unix(tm) lex(1) though.
You could build a C++ lexer. This means all the state information is held in an object.
Then it is just a matter of using the correct object!
I've been learning Ruby/Rails with vim. Tim Pope's rails.vim seems like a really good tool to traverse files with, but I keep getting these pesky "E345 can't find file in path" errors. I'm not vim expert yet, so the solution isn't obvious. Additionally, I've tried this and it doesn't apply to my problem.
As an example of the problem. I have a method format_name defined in app/helpers/application_helper.rb and it is used in app/helpers/messages_helper.rb. Within the latter file I put my cursor over the usage of format_name and then hit gf and I get that error. Similar disfunction with commands like ]f and [f
However, it works sometimes. I was able to gf from user to the app/models/user.rb
Ideas?
I think that is a limitation of rails.vim. It does not support “finding” bare methods. Supporting something like that would require one of the following:
an exhaustive search of all the source files for each “find” request
(which could be expensive with large projects),
“dumb” indexing of method names
(e.g. Exuberant Ctags and gControl-]; see :help g_CTRL-]), or
smart enough parsing of the code to make a good guess where the method might be defined
(which is hard to do properly).
If you know where the method is, you can extend many of the navigation commands with a method name:
:Rhelper application#format_name
But, you do not have to type all of that in. Assuming the cursor is on format_name you can probably just type:RhTabspaceappTab#Control-R Control-W (see :help c_CTRL-R_CTRL-W).
I would like to globally prevent LaTeX from hyphenating 'Objective-C'. I am aware of the \hyphenation command, but I don't see how I can make use of it. If I pass 'Objective-C' to this command, the dash will be treated as a hint to hyphenate the word there.
One solution I found is wrapping Objective-C into an mbox each time I use it. However, the document I am writing contains this name a lot, and wrapping it into an mbox each time is ugly (as is defining a command and using this over and over again in the source code).
Why is defining a new command ugly? It's how \LaTeX\ defines itself.
\def\ObjectiveC{\mbox{Objective-C}}
Use \nobreakdash. That's what LyX produces when I insert a nonbreakingdash and convert it to tex.
As suggested here, you could define a command like this:
\newcommand\dash{\nobreakdash-\hspace{0pt}}
and use it like this
Consider the $n$\dash dimensional manifold ...
Also, you could use the babel package and use "~ as a protected hyphen. I'm not sure if using babel is advisable when writing in english, though.