I'd like to find out which of the clang-tidy checks are possible to run with the -fix option, i.e. automatically generate fixed code.
I know all the modernize-* checks can do this and some other checks can too (like google-readability-casting) but nowhere did I find a complete list.
Is there a list somewhere? Or a method to find out other than reading the source of each and every check?
EDIT: Since clang-tidy 10 the fix option is included in the list of checks in the documentation.
The rest of my answer is still valid for versions 9 and lower.
grep --include=\*.cpp -rc './' -e "FixItHint"|grep -v ':0$' > FixItChecks.txt
I ran this grep command in the clang-tidy source directory. It counts the number of occurences of "FixItHint" string in all .cpp files and filters out files with zero occurences.
clang::FixItHint is a class that (according to documentation):
Annotates a diagnostic with some code that should be inserted, removed, or replaced to fix the problem.
I admit the method to obtain the list is somewhat crude however I did check multiple files and the results seem to be correct.
The cleaned-up and sorted list of checks with fixes:
abseil/StringFindStartswithCheck
android/CloexecCheck
boost/UseToStringCheck
bugprone/ArgumentCommentCheck
bugprone/BoolPointerImplicitConversionCheck
bugprone/CopyConstructorInitCheck
bugprone/InaccurateEraseCheck
bugprone/MacroParenthesesCheck
bugprone/MisplacedOperatorInStrlenInAllocCheck
bugprone/MoveForwardingReferenceCheck
bugprone/ParentVirtualCallCheck
bugprone/StringIntegerAssignmentCheck
bugprone/SuspiciousMemsetUsageCheck
bugprone/SuspiciousSemicolonCheck
bugprone/SuspiciousStringCompareCheck
bugprone/UnusedRaiiCheck
bugprone/VirtualNearMissCheck
cert/PostfixOperatorCheck
cppcoreguidelines/ProBoundsConstantArrayIndexCheck
cppcoreguidelines/ProTypeCstyleCastCheck
cppcoreguidelines/ProTypeMemberInitCheck
cppcoreguidelines/ProTypeStaticCastDowncastCheck
fuchsia/DefaultArgumentsCheck
fuchsia/RestrictSystemIncludesCheck
google/AvoidCStyleCastsCheck
google/ExplicitConstructorCheck
google/ExplicitMakePairCheck
google/GlobalVariableDeclarationCheck
google/TodoCommentCheck
llvm/IncludeOrderCheck
llvm/TwineLocalCheck
misc/DefinitionsInHeadersCheck
misc/RedundantExpressionCheck
misc/StaticAssertCheck
misc/UniqueptrResetReleaseCheck
misc/UnusedAliasDeclsCheck
misc/UnusedParametersCheck
misc/UnusedUsingDeclsCheck
modernize/AvoidBindCheck
modernize/DeprecatedHeadersCheck
modernize/LoopConvertCheck
modernize/MakeSmartPtrCheck
modernize/PassByValueCheck
modernize/RawStringLiteralCheck
modernize/RedundantVoidArgCheck
modernize/ReplaceAutoPtrCheck
modernize/ReplaceRandomShuffleCheck
modernize/ReturnBracedInitListCheck
modernize/ShrinkToFitCheck
modernize/UnaryStaticAssertCheck
modernize/UseAutoCheck
modernize/UseBoolLiteralsCheck
modernize/UseDefaultMemberInitCheck
modernize/UseEmplaceCheck
modernize/UseEqualsDefaultCheck
modernize/UseEqualsDeleteCheck
modernize/UseNoexceptCheck
modernize/UseNullptrCheck
modernize/UseOverrideCheck
modernize/UseTransparentFunctorsCheck
modernize/UseUncaughtExceptionsCheck
modernize/UseUsingCheck
objc/PropertyDeclarationCheck
performance/FasterStringFindCheck
performance/ForRangeCopyCheck
performance/InefficientAlgorithmCheck
performance/InefficientVectorOperationCheck
performance/MoveConstArgCheck
performance/TypePromotionInMathFnCheck
performance/UnnecessaryCopyInitialization
performance/UnnecessaryValueParamCheck
readability/AvoidConstParamsInDecls
readability/BracesAroundStatementsCheck
readability/ContainerSizeEmptyCheck
readability/DeleteNullPointerCheck
readability/IdentifierNamingCheck
readability/ImplicitBoolConversionCheck
readability/InconsistentDeclarationParameterNameCheck
readability/MisplacedArrayIndexCheck
readability/NamedParameterCheck
readability/NamespaceCommentCheck
readability/NonConstParameterCheck
readability/RedundantControlFlowCheck
readability/RedundantDeclarationCheck
readability/RedundantFunctionPtrDereferenceCheck
readability/RedundantMemberInitCheck
readability/RedundantSmartptrGetCheck
readability/RedundantStringCStrCheck
readability/RedundantStringInitCheck
readability/SimplifyBooleanExprCheck
readability/SimplifySubscriptExprCheck
readability/StaticAccessedThroughInstanceCheck
readability/StaticDefinitionInAnonymousNamespaceCheck
readability/StringCompareCheck
readability/UniqueptrDeleteReleaseCheck
Related
See below for the following code, and below that, the error that follows.
std::string source = "C:\\Users\\cambarchian\\Documents\\tested";
std::string destination = "C:\\Users\\cambarchian\\Documents\\tester";
std::filesystem::path sourcepath = source;
std::filesystem::path destpath = destination;
std::filesystem::copy_options::update_existing;
std::filesystem::copy(sourcepath, destpath);
terminate called after throwing an instance of 'std::filesystem::__cxx11::filesystem_error'
what(): filesystem error: cannot copy: File exists [C:\Users\cambarchian\Documents\tested] [C:\Users\cambarchian\Documents\tester]
Tried to use filesystem::copy, along with trying different paths. No luck with anything. Not too much I can write here as the problem is listed above, could be a simple formatting issue. That being said, it worked on my home computer using visual studio 2022, however using VS Code with gcc 11.2 gives me this issue.
Using:
filesystem::copy_file(oldPath, newPath, filesystem::copy_options::overwrite_existing);
The overloads of std::filesystem::copy are documented. You're using the first overload, but want the second:
void copy(from, to) which is equivalent to [overload 2, below] using copy_options::none
void copy(from, to, options)
Writing the statement std::filesystem::copy_options::update_existing; before calling copy doesn't achieve anything at all, whereas passing the option to the correct overload like
std::filesystem::copy(sourcepath, destpath,
std::filesystem::copy_options::update_existing);
should do what you want.
... it worked on my home computer using visual studio 2022 ...
you don't say whether the destination file existed in that case, which is the first thing you should check.
I put the copy_options within the copy function but it didn't work so I started moving it around, I probably should have mentioned that.
Randomly permuting your code isn't a good way of generating clean examples for others to help with.
In the rare event that hacking away at something does fix it, I strongly recommend pausing to figure out why. When you've hacked away at something and it still doesn't work, by all means leave comments to remind yourself what you tried, but the code itself should still be in a good state.
Still doesn't work when I write std::filesystem::copy(sourcepath, destpath, std::filesystem::copy_options::recursive)
Well, that's a different option, isn't it? Were you randomly permuting which copy_options you selected as well?
Trying recursive and update_existing yields the same issue.
The documentation says
The behavior is undefined if there is more than one option in any of the copy_options option group present in options (even in the copy_file group).
so you shouldn't be setting both anyway. There's no benefit to recursively copying a single file, but there may be a benefit to updating or overwriting one. If the destination already exists. Which, according to your error, it does.
Since you do have an error explicitly saying "File exists", you should certainly look at the "options controlling copy_file() when the file already exists" section of the table here.
Visual Studio 2022 fixed the problem
So I am having a problem when calling the command:
file( COPY ${src_dir} DESTINATION ${dest_dir} )
Half the time it works, and then half the time I get an error:
file COPY cannot set permissions on "${dest_dir}/subdir"
My issue is I have changed no permissions or touched these files in between execution. I would prefer to use this method to copy our files, as the other methods with add_custom_command/target does not seem to work on our side. I need to copy these files before our executable target is ultimately declared.
I would even be open to use a bash shell to do this copy command, but it has to be done at this specific point of cmake execution.
I have been wondering if file (COPY...) throws a return value, and if there is a way to possibly rerun the copy command if I get a return. Does anybody know if that is possible?
Can anybody give any help if they have run into this problem?
Thank you!
Edit:
I have already tried using different FILE_PERMISSIONS to see if it would function.
You might set permissions explicitly, with PERMISSIONS <permissions>, FILE_PERMISSIONS <permissions> and DIRECTORY_PERMISSIONS <permissions>, or skip setting-of-permissions through NO_SOURCE_PERMISSIONS.
You could hack in a ls -laR ${dest_dir} command to see if there's anything special going on in the filesystem at the time file(COPY ...) is invoked.
So, what I ended up doing is simply using this copy step in a while loop, because it usually works the 2'nd time, if not the first. Not an elegant way, and may only apply to my case, but please leave other answers if somebody can think of other methods.
I had some difficulties in overriding perl lib when testing perl codes when the .pl or .pm has use lib or unshift #INC, my question is:
Is it a bad idea to use use lib or unshift #INC in the production code since they are hard to test? The prove -lvr cannot override these too.
Code test.pl
push #INC, '/push/inc/lowest_priority';
use lib "/top/priority/use/lib/second_priority";
unshift #INC, "/unshift/inc/lib/first_priority";
foreach my $inc (#INC){
print "INC=>$inc\n";
}
set perl env
export PERL5LIB=/export/PERL5LIB/env/lib:$PERL5LIB
Output of perl -I/cmd/Iinclude/lib/ test.pl
INC=>/unshift/inc/lib/first_priority
INC=>/top/priority/use/lib/second_priority
INC=>/cmd/Iinclude/lib/
INC=>/export/PERL5LIB/env/lib
INC=>/usr/local/lib64/perl5
INC=>/usr/local/share/perl5
INC=>/usr/lib64/perl5/vendor_perl
INC=>/usr/share/perl5/vendor_perl
INC=>/usr/lib64/perl5
INC=>/usr/share/perl5
INC=>/push/inc/lowest_priority
I don't hard-code paths unless I have no other options.
In general, you don't want to hardcode things that you can provide to your program in some other fashion so it can respond to whatever environment it's in rather than only the environment where you developed it. One of those environments could be your testing environment.
You can set the library search path from outside the program, and that makes it more flexible.
And, since you hard-code them and add them at runtime, they are going to come after anything you've set previously. Here's what happens in your setting:
You start with the default #INC.
You start to "run" your program, you start the compilation phase. It compiles the entire program before it executes run-time statements.
As it compiles, it encounters the use lib and executes that pragma immediately. Now /top/priority/use/lib/second_priority is at the beginning of #INC.
For the rest of the compilation phase, /top/priority/use/lib/second_priority is the first thing in #INC. That's where subsequent use calls will look for things.
The compilation phase finishes and the program transitions into the run phase.
It encounters the push and executes that. Now /push/inc/lowest_priority is the last element of #INC.
It skips over the use lib because the compilation phase handled the pragma.
It encounters the unshift and executes that. Now /unshift/inc/lib/first_priority is the first item in #INC.
Subsequent require calls (a runtime feature) will look in /unshift/inc/lib/first_priority first.
I don't know where you expect to find the library you expected to load, but you have to supply the full path to it. There may be extra directories under the lib/ that matter and you haven't accounted for.
I might be misunderstanding your problem but local::lib allows you to "manually" tune your module path. You should be able to use it to control what paths are used for your test environment.
I have reinstalled emacs 24.2.50 on a new linux host and started a new dotEmacs config based on magnars emacs configuration. Since I have used CEDET to some success in my previous workflow I started configuring it. However, there is some strange behaviour whenever I load a C++ source file.
[This Part Is Solved]
As expected, semantic parses all included files (and during the initial setup parses all files specified by the semantic-add-system-include variables), but it prints this an error message that goes like this:
WARNING: semantic-find-file-noselect called for /usr/include/c++/4.7/vector while in set-auto-mode for /usr/include/c++/4.7/vector. You should call the responsible function into 'mode-local-init-hook'.
In the above example the error is printed for the STL vector but a corresponding error message is printed for every file included by the one I'm visiting and any subsequent includes. As a result it takes quite a long time to finish and unfortunately the process is repeated any type I open a new buffer.
[This Problem Is Solved Too]
Furthermore it looks like the parsing doesn't really work as when I place the point above a non-c primitive type (i.e. not int,double,float, etc) instead of printing the type's definition in the modeline an error message like
Idle Service Error semantic-idle-local-symbol-highlight-idle-function: "#<buffer DEPFETResolutionAnalysis.cc> - Wrong type argument: stringp, (((0) \"IndexMap\"))"
Idle Service Error semantic-idle-summary-idle-function: "#<buffer DEPFETResolutionAnalysis.cc> - Wrong type argument: stringp, ((\"fXBetween\" 0 nil nil))"
where DEPFETResolutionAnalysis.cc is the file & buffer I'm currently editing and IndexMap and fXBetween are types defined in files included by the file I'm editing/some file included by the file I'm editing.
I have not tested any further features of CEDET/semantic as the problem is pretty annoying. My cedet config can be found here.
EDIT: With the help of Alex Ott I kinda solved the first problem. It was due to my horrible cedet initialisation. See his first answer for the proper way to configure CEDET!
There still remains the problem with the Idle Service Error (which, when enabling global-semantic-idle-local-symbol-highlight-mode, occurs permanently, not only when checking the definition of the type at point).
And there is the new problem of how to disable the site-wise init file(s).
EDIT2: I have executed semantic-debug-idle-function in a buffer where the problem occurs and it produces a ~700kb [sic!] output. It looks like it is performing some operations on a data container which, by the looks of it, contains information on all the symbols defined in the files parsed. As I have parsed a rather large package (~20Mb source files) this table is rather large. Can semantic handle a database that large or is this impossible and the reason of my problem?
EDIT3: Deleting the content of ~/.semanticdb and reparsing all includes did the trick. I still need to disable the site-wise init files but as this is not related to CEDET I will close this question (the question related to the site-wise init files can be found here).
You need to change your init file so it will perform loading of CEDET only once, not in the hook that will be called for each .h/.hpp/.c/.cpp files. You can change this config as the base, and read more in following article.
The problem that you have is caused because Semantic is trying to analyze header files, and when it tries to open them, then its initialization routines are called again, and again...
The first problem was solved by correctly configuring CEDET which is discribed on Alex Ott's homepage. His answer solves this first problem. The config file specified in his answer is a great start for a nice config; I have used the very same to config CEDET for my needs.
The second problem vanished once I updated CEDET from 1.1 to the bazaar (repository) version, which is explained here and in Alex' article. Additionaly one must delete the content of the directory ~/.semanticdb (which contains the semantic database and was corrupted I guess).
I'd like to thank Alex Ott for his help and sticking with me throughout my journey to the solution :)
I'm getting a link time error:
WARNING: /home/gulevich/development/camac-fedorov/camac/linux/k0607-lsi6/camac-k0607-lsi6.o (.ctors): unexpected non-allocatable section.
Did you forget to use "ax"/"aw" in a .S file?
Note that for example <linux/init.h> contains
section definitions for use in .S files.
The code causing the error (assembly in C source):
# if defined(__ELF__)
# define __SECTION_FLAGS ", \"aw\" , #progbits"
/* writable flag needed for ld ".[cd]tors" sections bug workaround) */
# elif defined(__COFF__)
# define __SECTION_FLAGS ", \"dr\""
/* untested, may be writable flag needed */
# endif
asm
(
".section .ctors" __SECTION_FLAGS "\n"
".globl __ctors_begin__\n"
"__ctors_begin__:\n"
".previous\n"
);
Is there any way to fix this? The idea is to put a varaible __ctors_begin__ at the beginning of a certain memory section. This code is a legacy that worked fine using a different build system and older compiler.
Meaning of this assembly code explained in an answer to my previous question.
very long shot but is the section .ctors is defined like you want in the linker script? ld iirc has a verbose option to show the linker script.
A long shot:
Perhaps your linker is expecting ELF format (instead of COFF), and for some reason __ELF__ is not defined? Have you checked the preprocessor output for this particular build?
I would dobule check the value of __SECTION_FLAGS just to be sure that it indeed contains ax or aw. I'd also be sure that __COFF__ is not defined and that __ELF__ is. Failing that, it might be time to grab (is possible) a previous or future version of the compiler/linker and see if that fixes your problem. Perhaps you could compile your code as C++ and somehow let the compiler/linker/link scritps do what they are supposed to do? Dunno completely, but this is where I would start.
Sections work fine. So I'll ignore this warning.