Adding a Zircon module to clang-tidy for checks specific to the Zircon
kernel, and adding a checker to fuchsia-zx (for zircon) to flag instances
where specific objects are temporarily created.
Differential Revision: https://reviews.llvm.org/D44346
llvm-svn: 327590
Setting up the mapper part of the frontend framework for a clang-doc
tool. It creates a series of relevant matchers for declarations, and
uses the ToolExecutor to traverse the AST and extract the matching
declarations and comments. The mapper serializes the extracted
information to individual records for reducing and eventually doc
generation.
For a more detailed overview of the tool, see the design document on the
mailing list: http://lists.llvm.org/pipermail/cfe-dev/2017-December/056203.html
Differential Revision: https://reviews.llvm.org/D41102
llvm-svn: 327102
Summary:
Many architectures provide SIMD operations (e.g. x86 SSE/AVX, Power AltiVec/VSX,
ARM NEON). It is common that SIMD code implementing the same algorithm, is
written in multiple target-dispatching pieces to optimize for different
architectures or micro-architectures.
The C++ standard proposal P0214 and its extensions cover many common SIMD
operations. By migrating from target-dependent intrinsics to P0214 operations,
the SIMD code can be simplified and pieces for different targets can be unified.
Refer to http://wg21.link/p0214 for introduction and motivation for the
data-parallel standard library.
Subscribers: klimek, aemerson, mgorny, xazax.hun, kristof.beyls, hintonda, cfe-commits
Differential Revision: https://reviews.llvm.org/D42983
llvm-svn: 325272
Summary:
The existing option objc-property-declaration.Acronyms
replaces the built-in set of acronyms.
While this behavior is OK for clients that don't want the default
behavior, many clients may just want to add their own custom acronyms
to the default list.
This revision introduces a new option,
objc-property-declaration.IncludeDefaultAcronyms, which controls
whether the acronyms in objc-property-declaration.Acronyms are
appended to the default list (the default behavior) or whether they
replace.
I also updated the documentation.
Test Plan: make -j12 check-clang-tools
Reviewers: Wizard, hokein, klimek
Reviewed By: hokein
Subscribers: Eugene.Zelenko, cfe-commits
Differential Revision: https://reviews.llvm.org/D42261
llvm-svn: 323130
Summary:
We were missing some pretty common acronyms in the camelCase
property name check objc-property-declaration.
This expands the list and sorts it lexicographically, so we can
avoid duplicates.
Test Plan: make -j12 check-clang-tools
Reviewers: Wizard, hokein, klimek
Reviewed By: Wizard
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42253
llvm-svn: 322886
The usage of `goto` is discourage in C++ since forever. This check implements
a warning for every `goto`. Even though there are (rare) valid use cases for
`goto`, better high level constructs should be used.
`goto` is used sometimes in C programs to free resources at the end of
functions in the case of errors. This pattern is better implemented with
RAII in C++.
Reviewers: aaron.ballman, alexfh, hokein
Reviewed By: aaron.ballman
Subscribers: lebedev.ri, jbcoe, Eugene.Zelenko, klimek, nemanjai, mgorny, xazax.hun, kbarton, cfe-commits
Differential Revision: https://reviews.llvm.org/D41815
llvm-svn: 322626
And also enable it by default to be consistent with e.g. modernize-use-using.
This helps e.g. when running this check on client code where the macro is
provided by the system, so there is no easy way to modify it.
Reviewers: alexfh, piotrdz, hokein, ilya-biryukov
Reviewed By: alexfh
Differential Revision: https://reviews.llvm.org/D41716
llvm-svn: 321913
Examples:
* Always evaluates to 0:
```
int X;
if (0 & X) return;
```
* Always evaluates to ~0:
```
int Y;
if (Y | ~0) return;
```
* The symbol is unmodified:
```
int Z;
Z &= ~0;
```
Patch by: Lilla Barancsuk!
Differential Revision: https://reviews.llvm.org/D39285
llvm-svn: 321168
Supports a comma-separated list of check names to be disabled on the given line. Also supports * as a wildcard to disable all lint diagnostic messages on that line.
Patch by Anton (xgsa).
llvm-svn: 320713
Summary:
A user of the check opened a bugreport and reported that `std::exchange`
triggers a false positive. I adjusted the doc to include a list of known
(std) constructs that do trigger the issue with templates forgetting the
type alias.
Reviewers: aaron.ballman, alexfh, hokein
Reviewed By: aaron.ballman
Subscribers: klimek, nemanjai, xazax.hun, kbarton, cfe-commits
Differential Revision: https://reviews.llvm.org/D40829
llvm-svn: 319785
Summary:
This check finds the use of methods related to OSSpinlock in Objective-C code, which should be deprecated due to livelock issues.
The following method call will be detected:
- OSSpinlockLock()
- OSSpinlockTry()
- OSSpinlockUnlcok()
Reviewers: hokein, benhamilton
Reviewed By: benhamilton
Subscribers: klimek, cfe-commits, mgorny
Differential Revision: https://reviews.llvm.org/D40325
llvm-svn: 319098
Summary:
This is mainly a test diff to check the new Herald rule I
added in LLVM Phabricator to automatically Cc: cfe-commits on all
clang-tools-extra diffs.
Reviewers: Wizard, hokein, klimek
Reviewed By: Wizard
Subscribers: dlj, bkramer, sammccall
Differential Revision: https://reviews.llvm.org/D40180
llvm-svn: 319040
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
Summary:
This adds a note warning the users that the way the suggested fix seeds the
random number generator is poor.
Reviewers: hokein
Reviewed By: hokein
Subscribers: cfe-commits, xazax.hun
Differential Revision: https://reviews.llvm.org/D39787
llvm-svn: 317689
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:
I was just granted commit-after-approval access to SVN,
and @clattner recommended I try a test commit.
So, this tweaks the release notes as a test.
Reviewers: hokein, alexfh
Reviewed By: hokein
Subscribers: Wizard
Differential Revision: https://reviews.llvm.org/D39559
llvm-svn: 317261
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
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 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 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:
epoll_create() is better to be replaced by epoll_create1() with EPOLL_CLOEXEC
flag to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35367
llvm-svn: 311029
Summary:
epoll_create1() is better to set EPOLL_CLOEXEC flag to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35365
llvm-svn: 311028
Summary:
accept4() is better to set SOCK_CLOEXEC flag to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35363
llvm-svn: 311027
Summary:
accept() is better to be replaced by accept4() with SOCK_CLOEXEC
flag to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35362
llvm-svn: 311024
Summary:
inotify_init1() is better to set IN_CLOEXEC flag to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35368
llvm-svn: 310863
Summary:
inotify_init() is better to be replaced by inotify_init1() with IN_CLOEXEC flag to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35370
llvm-svn: 310861
Summary:
dup() is better to be replaced by fcntl() to avoid file descriptor leakage.
Differential Revision: https://reviews.llvm.org/D35364
llvm-svn: 310858
This reverts commit r310630.
The new code broke on Windows and was untested. On Linux, it was
selecting the "int" overload of operator<<, which definitely does not
print the right thing when fed a "Mode" char.
llvm-svn: 310661
Summary:
1. Refactor the structure of the code by adding a base class for all close-on-exec checks, which implements most of the needed functions.
2. memfd_create() is better to set MFD_CLOEXEC flag to avoid file descriptor leakage.
Reviewers: alexfh, aaron.ballman, hokein
Reviewed By: alexfh, hokein
Subscribers: Eugene.Zelenko, chh, cfe-commits, srhines, mgorny, JDevlieghere, xazax.hun
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D35372
llvm-svn: 310630
Summary: Adds redirections notes and the actual redirections in the documentation for hicpp
Patch by: Jonas Toth
Reviewers: aaron.ballman, hokein, alexfh
Reviewed By: aaron.ballman, hokein
Subscribers: JDevlieghere, xazax.hun
Differential Revision: https://reviews.llvm.org/D36355
llvm-svn: 310577
Summary:
This patch renames checks, check options and changes messages to use correct
term "implicit conversion" instead of "implicit cast" (which has been in use in
Clang AST since ~10 years, but it's still technically incorrect w.r.t. C++
standard).
* performance-implicit-cast-in-loop -> performance-implicit-conversion-in-loop
* readability-implicit-bool-cast -> readability-implicit-bool-conversion
- readability-implicit-bool-cast.AllowConditionalIntegerCasts ->
readability-implicit-bool-conversion.AllowIntegerConditions
- readability-implicit-bool-cast.AllowConditionalPointerCasts ->
readability-implicit-bool-conversion.AllowPointerConditions
Reviewers: hokein, jdennett
Reviewed By: hokein
Subscribers: mgorny, JDevlieghere, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D36456
llvm-svn: 310366
Summary:
The check doesn't fully support smart-ptr usages inside macros, which
may cause incorrect fixes, or even crashes, ignore them for now.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: JDevlieghere, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D36264
llvm-svn: 310050
Created new module bugprone and placed the check in that.
Finds memset() calls with potential mistakes in their arguments.
Replaces and extends the existing google-runtime-memset-zero-length check.
Cases covered:
* Fill value is a character '0'. Integer 0 might have been intended.
* Fill value is out of char range and gets truncated.
* Byte count is zero. Potentially swapped with the fill value argument.
Patch by: Reka Nikolett Kovacs
Differential Revision: https://reviews.llvm.org/D32700
llvm-svn: 308020
Summary: socket() is better to include SOCK_CLOEXEC in its type argument to avoid the file descriptor leakage.
Reviewers: chh, Eugene.Zelenko, alexfh, hokein, aaron.ballman
Reviewed By: chh, alexfh
Subscribers: srhines, mgorny, JDevlieghere, xazax.hun, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D34913
llvm-svn: 307818
Summary:
1. Rename android-file-open-flag to android-cloexec-open.
2. Handle a case when the function is passed as an argument of a function-like macro.
Reviewers: chh
Reviewed By: chh
Subscribers: srhines, mgorny, JDevlieghere, xazax.hun, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D34633
llvm-svn: 306728
Summary:
A follow-up on D34449:
* add `-std=c++11` to `.hpp` file by default.
* add constexpr function to test and doc.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: JDevlieghere, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D34771
llvm-svn: 306650
* Enforce 80 characters limit where appropriate
* Use slightly more descriptive names for searched locations
* Update docs to reflect D34269, which adds "Go To Declaration" functionality
llvm-svn: 306598
Summary:
A common source of security bugs is code that opens a file descriptors without using the O_CLOEXEC flag. (Without that flag, an opened sensitive file would remain open across a fork+exec to a lower-privileged SELinux domain, leaking that sensitive data.).
Add a new Android module and one checks in clang-tidy.
-- open(), openat(), and open64() should include O_CLOEXEC in their flags argument. [android-file-open-flag]
Links to part2 and part3:
https://reviews.llvm.org/D33745https://reviews.llvm.org/D33747
Reviewers: chh, alexfh, aaron.ballman, hokein
Reviewed By: alexfh, hokein
Subscribers: jbcoe, joerg, malcolm.parsons, Eugene.Zelenko, srhines, mgorny, xazax.hun, cfe-commits, krytarowski
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D33304
llvm-svn: 306165
Summary:
Finds compound statements which create next nesting level after `NestingThreshold` and emits a warning.
Do note that it warns about each compound statement that breaches the threshold, but not any of it's sub-statements, to have readable warnings.
I was able to find only one coding style referencing nesting:
- https://www.kernel.org/doc/html/v4.10/process/coding-style.html#indentation
> In short, 8-char indents make things easier to read, and have the added benefit of warning you when you’re nesting your functions too deep.
This seems too basic, i'm not sure what else to test. Are more tests needed?
Reviewers: alexfh, aaron.ballman, sbenza
Reviewed By: alexfh, aaron.ballman
Subscribers: xazax.hun
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D32942
llvm-svn: 305082
Summary:
New checker to replace dynamic exception
specifications
This is an alternative to D18575 which relied on reparsing the decl to
find the location of dynamic exception specifications, but couldn't
deal with preprocessor conditionals correctly without reparsing the
entire file.
This approach uses D20428 to find dynamic exception specification
locations and handles all cases correctly.
Reviewers: aaron.ballman, alexfh
Reviewed By: aaron.ballman, alexfh
Subscribers: xazax.hun, mgehre, malcolm.parsons, mgorny, JDevlieghere, cfe-commits, Eugene.Zelenko, etienneb
Patch by Don Hinton!
Differential Revision: https://reviews.llvm.org/D20693
llvm-svn: 304977
Add a clang-tidy check for using func__/FUNCTION__ inside lambdas. This
evaluates to the string operator(), which is almost never useful and almost
certainly not what the author intended.
Patch by Bryce Liu!
Differential Revision: https://reviews.llvm.org/D33497
llvm-svn: 304570
Summary:
The use-case is when renaming a widely used name, like a lower-level
class in a codebase and clang-rename is simply invoked for each
translation unit based on the compile database. In this case it's not
interesting to show errors: not finding the symbol means there is
simply nothing to do.
Reviewers: klimek
Reviewed By: klimek
Differential Revision: https://reviews.llvm.org/D32403
llvm-svn: 304534
Summary:
This patch makes modernize-use-emplace remove unnecessary make_ calls from push_back calls and turn them into emplace_back -- the same way make_pair calls are handled.
Custom make_ calls can be removed for custom tuple-like types -- two new options that control that are `TupleTypes` and `TupleMakeFunctions`. By default, the check removes calls to `std::make_pair` and `std::make_tuple`.
Eq.
```
std::vector<std::tuple<int, char, bool>> v;
v.push_back(std::make_tuple(1, 'A', true)); // --> v.emplace_back(1, 'A', true);
```
Reviewers: alexfh, aaron.ballman, Prazek, hokein
Reviewed By: Prazek
Subscribers: JDevlieghere, xazax.hun, JonasToth, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D32690
llvm-svn: 303145
Summary:
This patch makes modernize-use-emplace remove unnecessary make_ calls from push_back calls and turn them into emplace_back -- the same way make_pair calls are handled.
Custom make_ calls can be removed for custom tuple-like types -- two new options that control that are `TupleTypes` and `TupleMakeFunctions`. By default, the check removes calls to `std::make_pair` and `std::make_tuple`.
Eq.
```
std::vector<std::tuple<int, char, bool>> v;
v.push_back(std::make_tuple(1, 'A', true)); // --> v.emplace_back(1, 'A', true);
```
Reviewers: alexfh, aaron.ballman, Prazek, hokein
Reviewed By: Prazek
Subscribers: JDevlieghere, xazax.hun, JonasToth, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D32690
llvm-svn: 303139
This check flags postfix operator++/-- declarations,
where the return type is not a const object.
Differential Revision: https://reviews.llvm.org/D32743
llvm-svn: 302637
Summary:
And also enable it by default to be consistent with e.g.
modernize-use-using.
This helps e.g. when running this check on cppunit client code where the
macro is provided by the system, so there is no easy way to modify it.
Reviewers: alexfh, malcolm.parsons
Reviewed By: malcolm.parsons
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D32945
llvm-svn: 302429
Summary:
Add a simple documentation page for Clangd.
This will be useful for interested users and contributors to get basic information about how
to get started and the progress of Clangd.
Reviewers: krasimir, bkramer
Reviewed By: krasimir
Subscribers: Prazek, jbcoe, JDevlieghere, mgehre, JonasToth, kromanenkov, xazax.hun, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D31887
llvm-svn: 302191
Summary:
When there is a push_back with a call to make_pair, turn it into emplace_back and remove the unnecessary make_pair call.
Eg.
```
std::vector<std::pair<int, int>> v;
v.push_back(std::make_pair(1, 2)); // --> v.emplace_back(1, 2);
```
make_pair doesn't get removed when explicit template parameters are provided, because of potential problems with type conversions.
Reviewers: Prazek, aaron.ballman, hokein, alexfh
Reviewed By: Prazek, alexfh
Subscribers: JDevlieghere, JonasToth, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D32395
llvm-svn: 301651
This check will find occurrences of ``std::random_shuffle`` and replace it with ``std::shuffle``. In C++17 ``std::random_shuffle`` will no longer be available and thus we need to replace it.
Example of case that it fixes
```
std::vector<int> v;
// First example
std::random_shuffle(vec.begin(), vec.end());
```
Reviewers: hokein, aaron.ballman, alexfh, malcolm.parsons, mclow.lists
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D30158
llvm-svn: 301167
Summary:
The "performance-inefficient-vector-operation" check finds vector oprations in
for-loop statements which may cause multiple memory reallocations.
This is the first version, only detects typical for-loop:
```
std::vector<int> v;
for (int i = 0; i < n; ++i) {
v.push_back(i);
}
// or
for (int i = 0; i < v2.size(); ++i) {
v.push_back(v2[i]);
}
```
We can extend it to handle more cases like for-range loop in the future.
Reviewers: alexfh, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: zaks.anna, Eugene.Zelenko, mgorny, cfe-commits, djasper
Differential Revision: https://reviews.llvm.org/D31757
llvm-svn: 300534
This commit renames all of the safety functionality to be hicpp, adds an appropriate LICENSE.TXT, and updates the documentation accordingly.
llvm-svn: 298229
Alexander Kornienko