- Removed local isVirtual implementation in checkclass.cpp, use Function::isImplicitlyVirtual instead
- Don't bailout when we see C++-style casts in checkConst
- Don't bailout for this pattern "any << member << any"
- Improved/Fixed some test cases (-> #1305)
- Generalized CheckClass::noMemset:
-- Checking for all three mem...-functions for all patterns, generalized them so that we need less patterns
-- Use nextArgument() to jump over irrelevant arguments
- Replaced CheckClass::hasDeallocation by CheckClass::hasAllocation:
-- Reduced number of false negatives by returning also true whenever a member variable is allocated (also without previous deallocation)
-- Reduced code duplication
- Removed indendation counter and redundant variable in CheckClass::initializeVarList
gcc warning:
lib/checkclass.cpp: In member function ‘void CheckClass::checkConst()’:
lib/checkclass.cpp:1197: warning: declaration of ‘name’ shadows a member of 'this'
Rename local variable 'name' to 's'.
Signed-off-by: Stefan Weil <sw@weilnetz.de>
Refactorizations:
- Replaced another single-token-pattern
- Replaced a "continue" with a "break" statement, because its safe to assume that only one variable with a specific ID can exist in a scope
- Fixed#3628
- Added support for friend
Improved symbol database:
- friend scopes are now set
- Added findScopeByName function
Refactorizations:
- Removed some unnecessary "virtual" keywords
- Removed unnecessary _filename member variable, pass it as argument instead
- Made CppCheck::replaceAll static, since it is independant from a specific CppCheck instance, Pass string to be modified by reference
2) Clarify some comments in 'Tokenizer::simplifyFlowControl' and in 'Tokenizer::eraseDeadCode';
3) Add some 'const' variables inside 'Tokenizer::eraseDeadCode'.
"information" severity is documented in lib/errorlogger.h as:
Checking information.
Information message about the checking (process) itself. These
messages inform about header files not found etc issues that are
not errors in the code but something user needs to know.
It IS NOT for errors in the code. All the current "information"-
severity errors fit nicely into description of the "style"-
severity.
We definitely need to separate processing information and actual
errors in the code. It is highly confusing for users to mix these
two different things. Hence all current "information" code error
messages are moved to "style" category.
Ticket: #3165 (Stop misusing the 'information' error severity!)