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
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
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
This originally started out here in dev, but I moved it to another
file when it became clear this wouldn't work on non-Windows.
Unfortunately I forgot to remove it from this file. Test is still
live, just in another source file.
llvm-svn: 316247
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
check_clang_tidy.py currently only handles C and C++ source files.
This extends the logic to also handle Objective-C (.m) and
Objective-C++ (.mm) files.
However, by default, clang compiles .m/.mm files using Objective-C 1.0
syntax. Objective-C 2.0 has been the default in Xcode for about 10
years, and Objective-C Automatic Reference Counting (ARC) for about 6
years, so this enables both by default.
(Clients which actually want to test clang-tidy checks for Objective-C
1.0 or non-ARC files can pass custom flags to check_clang_tidy.py
after --, which will disable the Objective-C 2.0 and ARC flags).
I did not add logic to handle running clang-tidy on Objective-C header
files alone; they also use the .h file extension, so we'd need to
look inside their contents.
I included a new test to confirm the new behavior.
Depends On D38963
Patch by Ben Hamilton!
llvm-svn: 316090
Summary:
Currently, check_clang_tidy.py includes logic to select default
clang flags based on the extension of the source filename passed
as the first argument.
Since the source filename might be a temporary or test file with an
arbitrary extension unrelated to the file type, this adds the ability
to override the logic the same way `clang-format`'s -assume-filename=
parameter does.
I included a test with a nonstandard file extension. I confirmed
when I modified the warning message that the new test failed,
and that it passed again when I restored the warning message.
Ran tests with:
% cmake -G Ninja /path/to/llvm
% ninja check-clang-tools
Patch by Ben Hamilton!
Reviewers: hokein, alexfh
Reviewed By: hokein
Subscribers: alexfh
Differential Revision: https://reviews.llvm.org/D38963
llvm-svn: 316066
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
I tried to silence lit with `| count 0`, which did not work.
Other testcases did not have `-- --` but only `--` in the RUN line.
Maybe this fixes the problem.
llvm-svn: 314812
This patch removes the targetspecification of a testcase, that broke
for ARM. The underlying problem was fixed which makes it unnecessary to
specify the target architecture (problem was the signedness of `char`).
Committing without review was accepted in https://reviews.llvm.org/D38399
by aaron.ballman.
llvm-svn: 314811
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
Gabor Horvath