A possible error is to write `malloc(strlen(s+1))` instead of
`malloc(strlen(s)+1)`. Unfortunately the former is also valid syntactically,
but allocates less memory by two bytes (if `s` is at least one character long,
undefined behavior otherwise) which may result in overflow cases. This check
detects such cases and also suggests the fix for them.
Fix for r318906, forgot to add new files.
llvm-svn: 318907
A possible error is to write `malloc(strlen(s+1))` instead of
`malloc(strlen(s)+1)`. Unfortunately the former is also valid syntactically,
but allocates less memory by two bytes (if s` is at least one character long,
undefined behavior otherwise) which may result in overflow cases. This check
detects such cases and also suggests the fix for them.
llvm-svn: 318906
The address sanitizer found a stackoverflow with this patch.
There is no obvious fix. This patch will be reapplied when the problem
is found.
llvm-svn: 318670
Summary:
This check searches for missing `else` branches in `if-else if`-chains and
missing `default` labels in `switch` statements, that use integers as condition.
It is very similar to -Wswitch, but concentrates on integers only, since enums are
already covered.
The option to warn for missing `else` branches is deactivated by default, since it is
very noise on larger code bases.
Running it on LLVM:
{F5354858} for default configuration
{F5354866} just for llvm/lib/Analysis/ScalarEvolution.cpp, the else-path checker is very noisy!
Reviewers: alexfh, aaron.ballman, hokein
Reviewed By: aaron.ballman
Subscribers: lebedev.ri, Eugene.Zelenko, cfe-commits, mgorny, JDevlieghere, xazax.hun
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D37808
llvm-svn: 318600
Finds copy constructors where the constructor don't call
the copy constructor of the base class.
```
class X : public Copyable {
X(const X &other) {} // Copyable(other) is missing
};
```
Differential Revision: https://reviews.llvm.org/D33722
llvm-svn: 318522
Summary:
This is a small check to avoid throwing objc exceptions.
In specific it will detect the usage of @throw statement and throw warning.
Reviewers: hokein, benhamilton
Reviewed By: hokein, benhamilton
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D40058
llvm-svn: 318366
Summary:
This check finds property declarations in Objective-C files that do not follow the pattern of property names in Apple's programming guide. The property name should be in the format of Lower Camel Case or with some particular acronyms as prefix.
Example:
@property(nonatomic, assign) int lowerCamelCase;
@property(nonatomic, strong) NSString *URLString;
Test plan: ninja check-clang-tools
Reviewers: benhamilton, hokein
Reviewed By: hokein
Subscribers: cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D39829
llvm-svn: 318117
Redundant Expression Checker is updated to be able to detect expressions that
contain macros. Also, other small details are modified to improve the current
implementation.
The improvements in detail are as follows:
* Binary and ternary operator expressions containing two constants, with at
least one of them from a macro, are detected and tested for redundancy.
Macro expressions are treated somewhat differently from other expressions,
because the particular values of macros can vary across builds.
They can be considered correct and intentional, even if macro values equal,
produce ranges that exclude each other or fully overlap, etc.
* The code structure is slightly modified: typos are corrected,
comments are added and some functions are renamed to improve comprehensibility,
both in the checker and the test file. A few test cases are moved to another
function.
* The checker is now able to detect redundant CXXFunctionalCastExprs as well.
A corresponding test case is added.
Patch by: Lilla Barancsuk!
Differential Revision: https://reviews.llvm.org/D38688
llvm-svn: 317570
Summary:
This is a new checker for objc files in clang-tidy.
The new check finds global variable declarations in Objective-C files that are not follow the pattern of variable names in Google's Objective-C Style Guide.
All the global variables should follow the pattern of "g[A-Z].*" (variables) or "k[A-Z].*" (constants). The check will suggest a variable name that follows the pattern
if it can be inferred from the original name.
Patch by Yan Zhang!
Reviewers: benhamilton, hokein, alexfh
Reviewed By: hokein
Subscribers: Eugene.Zelenko, mgorny
Differential Revision: https://reviews.llvm.org/D39391
llvm-svn: 317552
Unfortunately, these python scripts are not tested currently. I did the testing
manually on LLVM by editing the CMake generated compilation database to
contain relative paths for some of the files.
Differential Revision: https://reviews.llvm.org/D39603
llvm-svn: 317468
An installation rule for the executable with the correct component is
already created by `add_clang_tool`, so the rule in this file is
redundant. Correct the installation component for the Python scripts so
that they also get installed by `install-clang-tidy`.
llvm-svn: 317155
Summary:
The C++ standard allows implementations to choose the underlying type for
bitmask types (e.g. std::ios_base::openmode). MSVC implemented some of them
as signed integers resulting in warnings for usual code like
`auto dd = std::ios_base::badbit | std::ios_base::failbit;`
These false positives were reported in https://bugs.llvm.org/show_bug.cgi?id=34845
The fix allows bitwise |,&,^ for known standard bitmask types under the condition
that both operands are such bitmask types.
Shifting and bitwise complement are still forbidden.
Reviewers: aaron.ballman, alexfh, hokein
Reviewed By: aaron.ballman
Subscribers: xazax.hun
Differential Revision: https://reviews.llvm.org/D39099
llvm-svn: 316767
Summary:
This is part 3 of 3 of a series of changes to improve Objective-C
linting in clang-tidy.
This adds a new clang-tidy check `objc-forbidden-subclassing` which
ensures clients do not create subclasses of Objective-C classes which
are not designed to be subclassed.
(Note that for code under your control, you should use
__attribute__((objc_subclassing_restricted)) instead -- this
is intended for third-party APIs which cannot be modified.)
By default, the following classes (which are publicly documented
as not supporting subclassing) are forbidden from subclassing:
ABNewPersonViewController
ABPeoplePickerNavigationController
ABPersonViewController
ABUnknownPersonViewController
NSHashTable
NSMapTable
NSPointerArray
NSPointerFunctions
NSTimer
UIActionSheet
UIAlertView
UIImagePickerController
UITextInputMode
UIWebView
Clients can set a CheckOption
`objc-forbidden-subclassing.ClassNames` to a semicolon-separated
list of class names, which overrides this list.
Test Plan: `ninja check-clang-tools`
Patch by Ben Hamilton!
Reviewers: hokein, alexfh
Reviewed By: hokein
Subscribers: saidinwot, Wizard, srhines, mgorny, xazax.hun
Differential Revision: https://reviews.llvm.org/D39142
llvm-svn: 316744
Summary:
This is part 1 of 3 of a series of changes to improve Objective-C
linting in clang-tidy.
This introduces a new clang-tidy module, `objc`, specifically for
Objective-C / Objective-C++ checks.
The module is currently empty; D39142 adds the first check.
Test Plan: `ninja check-clang-tools`
Patch by Ben Hamilton!
Reviewers: hokein, alexfh
Reviewed By: hokein
Subscribers: Wizard, mgorny
Differential Revision: https://reviews.llvm.org/D39188
llvm-svn: 316643
To get MS-style inline assembly, we need to link in the various
backends. Some other clang tools already do this, and this issue
has been raised with clang-tidy several times, indicating there
is sufficient desire to make this work.
Differential Revision: https://reviews.llvm.org/D38549
llvm-svn: 316246
Summary:
This patch introduces support for legacy C-style resource functions that must obey
the 'owner<>' semantics.
- added legacy creators like malloc,fopen,...
- added legacy consumers like free,fclose,...
This helps codes that mostly benefit from owner:
Legacy, C-Style code that isn't feasable to port directly to RAII but needs a step in between
to identify actual resource management and just using the resources.
Reviewers: aaron.ballman, alexfh, hokein
Reviewed By: aaron.ballman
Subscribers: nemanjai, JDevlieghere, xazax.hun, kbarton
Differential Revision: https://reviews.llvm.org/D38396
llvm-svn: 316092
This patch introduces a note for variable declaration that are later deleted.
Adds FIXME notes for possible automatic type-rewriting positions as well.
Reviewed by aaron.ballman
Differential: https://reviews.llvm.org/D38411
llvm-svn: 314913
The bug happened with stream operations, that were not recognized in all cases.
Even there were already existing test for streaming classes, they did not catch this bug.
Adding the isolated example to the existing tests did not trigger the bug.
Therefore i created a new isolated file that did expose the bug indeed.
Differential: https://reviews.llvm.org/D38399
reviewed by aaron.ballman
llvm-svn: 314808
Summary:
Bug: https://bugs.llvm.org/show_bug.cgi?id=34449
**Problem:**
Clang-tidy check misc-unused-parameters comments out parameter name omitting following characters (e.g. square brackets) what results in its complete removal. Compilation errors might occur after clang-tidy fix as well.
**Patch description:**
Changed removal range. The range should end after parameter name, not after whole parameter declarator (which might be followed by e.g. square brackets).
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: JDevlieghere, xazax.hun, cfe-commits
Tags: #clang-tools-extra
Patch by Pawel Maciocha!
Differential Revision: https://reviews.llvm.org/D37846
llvm-svn: 313355
Summary:
Bug: https://bugs.llvm.org/show_bug.cgi?id=34450
**Problem:**
Clang-tidy check misc-unused-parameters omits parameter default value what results in its complete removal. Compilation errors might occur after clang-tidy fix.
**Patch description:**
Changed removal range. The range should end after parameter declarator, not after whole parameter declaration (which might contain a default value).
Reviewers: alexfh, xazax.hun
Reviewed By: alexfh
Subscribers: JDevlieghere, cfe-commits
Tags: #clang-tools-extra
Patch by Pawel Maciocha!
Differential Revision: https://reviews.llvm.org/D37566
llvm-svn: 313150
This check implements the typebased semantic of `gsl::owner`.
Meaning, that
- only `gsl::owner` is allowed to get `delete`d
- `new` expression must be assigned to `gsl::owner`
- function calls that expect `gsl::owner` as argument, must get either an owner
or a newly created and recognized resource (in the moment only `new`ed memory)
- assignment to `gsl::owner` must be either a resource or another owner
- functions returning an `gsl::owner` are considered as factories, and their result
must be assigned to an `gsl::owner`
- classes that have an `gsl::owner`-member must declare a non-default destructor
There are some problems that occur when typededuction is in place.
For example `auto Var = function_that_returns_owner();` the type of `Var` will not be
an `gsl::owner`. This case is catched, and explicitly noted.
But cases like fully templated functions
```
template <typename T>
void f(T t) { delete t; }
// ...
f(gsl::owner<int*>(new int(42)));
```
Will created false positive (the deletion is problematic), since the type deduction
removes the wrapping `typeAlias`.
Codereview in D36354
llvm-svn: 313067
This check implements the typebased semantic of `gsl::owner`.
Meaning, that
- only `gsl::owner` is allowed to get `delete`d
- `new` expression must be assigned to `gsl::owner`
- function calls that expect `gsl::owner` as argument, must get either an owner
or a newly created and recognized resource (in the moment only `new`ed memory)
- assignment to `gsl::owner` must be either a resource or another owner
- functions returning an `gsl::owner` are considered as factories, and their result
must be assigned to an `gsl::owner`
- classes that have an `gsl::owner`-member must declare a non-default destructor
There are some problems that occur when typededuction is in place.
For example `auto Var = function_that_returns_owner();` the type of `Var` will not be
an `gsl::owner`. This case is catched, and explicitly noted.
But cases like fully templated functions
```
template <typename T>
void f(T t) { delete t; }
// ...
f(gsl::owner<int*>(new int(42)));
```
Will created false positive (the deletion is problematic), since the type deduction
removes the wrapping `typeAlias`.
Please give your comments :)
llvm-svn: 313043
This check is relatively simple, and is often being used
as an example. I'm aware of at least two cases, when
simply copying the FunctionASTVisitor class to a new
check resulted in a rather unobvious segfault. Having it
in anonymous namespace prevents such a problem.
No functionality change, so i opted to avoid phabricator,
especially since clang-tidy reviews are seriously jammed.
llvm-svn: 312912
This patch will introduce even more aliases for the hicpp-module to already existing
checks and is a follow up for D30383 finishing the other sections.
It fixes a forgotten highlight in hicpp-braces-around-statements.rst, too.
llvm-svn: 312901
Summary:
This patch is a followup to the first revision D36583, that had problems with
generic code and its diagnostic messages, which were found by @lebedev.ri
Reviewers: alexfh, aaron.ballman, lebedev.ri, hokein
Reviewed By: aaron.ballman, lebedev.ri
Subscribers: klimek, sbenza, cfe-commits, JDevlieghere, lebedev.ri, xazax.hun
Differential Revision: https://reviews.llvm.org/D37060
llvm-svn: 312134
Alexander Kornienko