I use Cppcheck 1.70 for checking C++-Builder projects. I get a lot of style warnings like this
[source\DbgRecMain.cpp:452]: (style) The function 'FormResize' is never used.
These functions are event handlers that are used, but not explicitly from within the C++ code: they are bound by the VCL runtime after loading the corresponding form or data module. Naturally, Cppcheck does not check the DFM files, that's why it cannot detect the references between events and handlers defined there.
Some options that come to my mind
Adding some explicit references, but this have to be maintained by hand.
Suppressing all warnings of this kind, but this would hide really dead code.
How can I specifically suppress these warnings about apparently unused event handlers?
There is a chapter in the CppCheck documentation about suppressing warnings/errors. Chapter 6.2 in particular will be useful to you, as you will be able to suppress warnings about the individual event handlers as needed:
Chapter 6. Suppressions
If you want to filter out certain errors you can suppress these.
6.1. Suppressing a certain error type
You can suppress certain types of errors. The format for such a suppression is one of:
[error id]:[filename]:[line]
[error id]:[filename2]
[error id]
The error id is the id that you want to suppress. The easiest way to get it is to use the --xml command line flag. Copy and paste the id string from the XML output. This may be * to suppress all warnings (for a specified file or files).
The filename may include the wildcard characters * or ?, which match any sequence of characters or any single character respectively. It is recommended that you use "/" as path separator on all operating systems.
6.1.1. Command line suppression
The --suppress= command line option is used to specify suppressions on the command line. Example:
cppcheck --suppress=memleak:src/file1.cpp src/
6.1.2. Listing suppressions in a file
You can create a suppressions file. Example:
// suppress memleak and exceptNew errors in the file src/file1.cpp
memleak:src/file1.cpp
exceptNew:src/file1.cpp
// suppress all uninitvar errors in all files
uninitvar
Note that you may add empty lines and comments in the suppressions file.
You can use the suppressions file like this:
cppcheck --suppressions-list=suppressions.txt src/
6.2. Inline suppressions
Suppressions can also be added directly in the code by adding comments that contain special keywords. Before adding such comments, consider that the code readability is sacrificed a little.
This code will normally generate an error message:
void f() {
char arr[5];
arr[10] = 0;
}
The output is:
# cppcheck test.c
Checking test.c...
[test.c:3]: (error) Array ’arr[5]’ index 10 out of bounds
To suppress the error message, a comment can be added:
void f() {
char arr[5];
// cppcheck-suppress arrayIndexOutOfBounds
arr[10] = 0;
}
Now the --inline-suppr flag can be used to suppress the warning. No error is reported when invoking cppcheck this way:
cppcheck --inline-suppr test.c
Also see the following questions for more details:
How to use cppcheck's inline suppression filter option for C++ code?
Can I include cppcheck suppression within a function header?
Related
I'm wondering why if the compiler directives was typed on multi lines will effects the selected IDE error line.
For example:
{$SETPEFlAGS IMAGE_FILE_DEBUG_STRIPPED or
IMAGE_FILE_LINE_NUMS_STRIPPED or
IMAGE_FILE_LOCAL_SYMS_STRIPPED or
IMAGE_FILE_RELOCS_STRIPPED}
.....
procedure Foo();
begin
WriteLn('1');
WWriteLn('2');
WriteLn('3');
WriteLn('4');
WriteLn('5');
end;
IDE Error
[dcc32 Error] Crypter.dpr(29): E2003 Undeclared identifier: 'WWriteLn'
Inside the source code the selected line is WriteLn('5'); not WWriteLn('2');
But if the compiler directives was typed on this way (one line) :
{$SETPEFlAGS IMAGE_FILE_DEBUG_STRIPPED or IMAGE_FILE_LINE_NUMS_STRIPPED or IMAGE_FILE_LOCAL_SYMS_STRIPPED or IMAGE_FILE_RELOCS_STRIPPED}
Will fix the issue!.
If things are as you say, then this is a defect in the IDE. Report the issue as a bug to Quality Portal.
It's easy to work around the issue. Simply don't use multi-line directives. In this case you can extract the flag into a separate constant and refer to it in the directive.
const
PEFlags = IMAGE_FILE_DEBUG_STRIPPED or
IMAGE_FILE_LINE_NUMS_STRIPPED or
IMAGE_FILE_LOCAL_SYMS_STRIPPED or
IMAGE_FILE_RELOCS_STRIPPED;
{$SETPEFlAGS PEFlags}
The reason I hesitate in the first paragraph is that what you describe would also occur if the linefeeds were incorrect. If your linefeeds are not CR+LF then the IDE gets confused about line numbers. So, it's worth checking that your linefeeds are CR+LF. You could simply re-type the code and the linefeeds will be correct. Typically you get mixed up linefeeds when you paste from another source.
I'm getting an error from Clang when using CLANG_WARN_DOCUMENTATION_COMMENTS on a doxygen block that contains following line
\post \ref something == somethingelse
The warning says "Empty paragraph passed to '\post' command"
Is this a valid use of \post?
If it is, does anyone know if there's a way to suppress this warning without disabling all documentation warnings?
Cheers.
I am using the clang compiler on windows. I used the installer from the LLVM website. Sometimes it gives me a compiler error.
clang -I./include main.c CoreFoundation.dll
it gives:
In file included from main.c:4:
In file included from ./include\CoreFoundation/CFNumberFormatter.h:110:
./include\CoreFoundation/CFXMLParser.h:159:81: error: unknown type name 'CFXMLNodeRef'
typedef void * (*CFXMLParserCreateXMLStructureCallBack)(CFXMLParserRef parser,
CFXMLNodeRef nodeDesc, void *info);
...
and sometimes this..
In file included from main.c:4:
In file included from ./include\CoreFoundation/CoreFoundation.h:86:
./include\CoreFoundation/CFDateFormatter.h:104:105: error: unknown type name 'CFDateRef'; did you mean 'CFDataRef'?
CFStringRef CFDateFormatterCreateStringWithDate(CFAllocatorRef allocator, CFDateFormatterRef formatter, CFDateRef date) AVAILABLE_MAC_OS_X_VERSION_10_3_AND_LATER;
...
...and other similar warnings, seemingly randomly choosing where to stop. Sometimes it compiles through without error. When it gives an error, they seem to be be about not finding a symbol from an included file. It doesn't complain about not finding the file. But it doesn't consistently stop at the same point and sometimes compiles successfully.
I can reproduce this "error" under Linux with gcc. I even get the "report this compiler bug pls" message.
When it gives an error, they seem to be be about not finding a symbol from an included file
You can get this:
if you compile with multiple threads (eg. make -j8)
if you abort the compile and then start it again without "cleaning" all obj files
if you compiled your source, changed something and compile without "cleaning"
if your compiler/make/build process changes the order every time... (had this with cmake and opencv 3 source)
I am using analyzer_experimental to parse a Dart file into a CompilationUnit:
import 'package:analyzer_experimental/analyzer.dart';
var unit;
try {
unit = parseDartFile(path);
} on AnalyzerErrorGroup catch(e){
print(e);
}
The above code will catch any parsing errors encountered.
I am also interested in seeing any warnings associated with the file (e.g. 'Undefined name "foo"'). I know that the experimental_analyzer library has the capability to generate these warnings when running from the command line but it does not seem to be possible to get the warnings programmatically, without directly referencing classes in the src folder (which seems like a bad idea).
Is there any way to achieve this?
It's likely this package was very incomplete at the time.
There's now an analyzer package on pub and also a (work-in-progress) STDIN/STDOUT Analyzer Service aimed to help making tooling support easier for IDE extension authors.
I've been using fslex and fsyacc, and the F# source files (.fs they generate from the lexer (.fsl) and parser (.fsp) rules refer to the original .fsl (and sometimes to the same .fs source file) all over the place with statement such as this (numbers are line numbers):
lex.fs
1 # 1 "/[PROJECT-PATH-HERE]/lex.fsp
...
16 # 16 "/PROJECT-PATH-HERE]/lex.fs
17 // This is the type of tokens accepted by the parser
18 type token =
19 | EOF
...
Also, the .fs files generated by pars.fsp do the same kind of thing, but additionaly reference to the F# signature file (.fsi) generated alongside it. What does any of this do/mean?
The annotations you see in the generated code are F# Compiler Directives (specifically, the 'line' directive).
The 'line' directive makes it so that when the F# compiler needs to emit a warning/error message for some part of the generated code, it has a way to determine which part of the original file corresponds to that part of the generated code. In other words, the F# compiler can generate a warning/error message referencing the original code which is the basis of the generated code causing the error.