Summary:
The current Objective-C global variable declaration check restricts naming that is permitted by the Google Objective-C style guide.
The Objective-C style guide states the following:
"Global and file scope constants should have an appropriate prefix. [...] Constants may use a lowercase k prefix when appropriate"
http://google.github.io/styleguide/objcguide#constants
This change fixes the check to allow two or more capital letters as an appropriate prefix. This change intentionally avoids making a decision regarding whether to flag constants that use a two letter prefix (two letter prefixes are reserved by Apple¹ but many projects seem to violate this guideline).
This change eliminates an important category of false positives (constants prefixed with '[A-Z]{2,}') at the cost of introducing a less important category of false negatives (constants prefixed with only '[A-Z]'). The false positives are observed in standard recommended code while the false negatives occur in non-standard unrecommended code. The number of eliminated false positives is expected to be significantly larger than the number of exposed false negatives.
❧
(1)
"Two-letter prefixes like these are reserved by Apple for use in framework classes."
https://developer.apple.com/library/content/documentation/Cocoa/Conceptual/ProgrammingWithObjectiveC/Conventions/Conventions.html
Reviewers: aaron.ballman, Wizard, hokein, benhamilton
Reviewed By: aaron.ballman, Wizard
Subscribers: aaron.ballman, cfe-commits
Differential Revision: https://reviews.llvm.org/D43581
llvm-svn: 326046
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
Updating the fuchsia-multiple-inheritance to gracefully handle unknown
record types (e.g. templatized classes) by simply continuing, rather
than asserting and failing.
Fixes PR36052.
Differential Revision: https://reviews.llvm.org/D43223
llvm-svn: 325015
Updating fuchsia-multiple-inheritance to not crash when a record
inherits a template.
Fixes PR36052.
Differential Revision: https://reviews.llvm.org/D42918
llvm-svn: 324432
Summary:
The following Objective-C code currently incorrectly triggers
clang-tidy's performance-unnecessary-value-param check:
```
% cat /tmp/performance-unnecessary-value-param-arc.m
void foo(id object) { }
clang-tidy /tmp/performance-unnecessary-value-param-arc.m
-checks=-\*,performance-unnecessary-value-param -- -xobjective-c
-fobjc-abi-version=2 -fobjc-arc
1 warning generated.
/src/llvm/tools/clang/tools/extra/test/clang-tidy/performance-unnecessary-value-param-arc.m:10:13:
warning: the parameter 'object' is copied for each invocation but only
used as a const reference; consider making it a const reference
[performance-unnecessary-value-param]
void foo(id object) { }
~~ ^
const &
```
This is wrong for a few reasons:
1) Objective-C doesn't have references, so `const &` is not going to help
2) ARC heavily optimizes the "expensive" copy which triggers the warning
This fixes the issue by disabling the warning for non-C++, as well as
disabling it for objects under ARC memory management for
Objective-C++.
Fixes https://bugs.llvm.org/show_bug.cgi?id=32075
Test Plan: New tests added. Ran tests with `make -j12 check-clang-tools`.
Reviewers: alexfh, hokein
Reviewed By: hokein
Subscribers: stephanemoore, klimek, xazax.hun, cfe-commits, Wizard
Differential Revision: https://reviews.llvm.org/D42812
llvm-svn: 324097
Summary:
Currently, add_new_check.py assumes all checks are for C++ code.
This adds a new argument --language=[LANG] to add_new_check.py
so authors of new checks can specify that the test file should
be in a different language.
For example, authors can pass --language=objc for Objective-C
clang-tidy checks.
Reviewers: hokein, alexfh
Reviewed By: alexfh
Subscribers: Wizard, xazax.hun
Differential Revision: https://reviews.llvm.org/D39141
llvm-svn: 323919
Summary:
C++2a allows bitfields to have default member initializers.
Add support for this to clang-tidy's cppcoreguidelines-pro-type-member-init check.
Reviewers: aaron.ballman, alexfh
Reviewed By: aaron.ballman
Subscribers: klimek, nemanjai, xazax.hun, kbarton, cfe-commits
Differential Revision: https://reviews.llvm.org/D42426
llvm-svn: 323227
Summary:
C++2a allows bitfields to have default member initializers.
Add support for this to clang-tidy's modernize-use-default-member-init check.
Reviewers: aaron.ballman, alexfh
Reviewed By: aaron.ballman
Subscribers: klimek, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D42413
llvm-svn: 323208
Summary:
It allows to remap and override files and directories on disk when
running clang-tidy. The intended use case for the flag is running
standalone clang-tidy binary for IDE and editor integration.
Patch by Vladimir Plyashkun.
Reviewers: alexfh, benlangmuir, ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: ilya-biryukov, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D41535
llvm-svn: 323196
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
Summary:
A follow-up fix of rL311652.
The previous `vector` in our test is different with `std::vector`, so
The check still generates fixes for std::vector (`auto p =
std::unique_ptr<Foo>(new Foo({1,2,3}))`) in real world, the patch makes the
vector behavior in test align with std::vector (both AST nodes are the same now).
Reviewers: ilya-biryukov, alexfh
Reviewed By: ilya-biryukov
Subscribers: klimek, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D41852
llvm-svn: 322822
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
Summary:
Fixes bug 34701
When we encounter a namespace find the location of the left bracket.
Then if the text between the name and the left bracket contains a ':'
then it's a C++17 nested namespace.
Reviewers: #clang-tools-extra, alexfh, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: curdeius, cfe-commits, krasimir, JonasToth, JDevlieghere, xazax.hun
Tags: #clang-tools-extra
Patch by Alexandru Octavian Buțiu!
Differential Revision: https://reviews.llvm.org/D38284
llvm-svn: 322274
Summary:
Fix DanglingHandleCheck to handle the final implementation of std::string and std::string_view.
These use a conversion operator instead of a conversion constructor.
Reviewers: hokein
Subscribers: klimek, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D41779
llvm-svn: 322002
Summary:
google-objc-global-variable-declaration currently triggers on
valid code like:
- (void)foo {
static dispatch_once_t onceToken;
dispatch_once(&onceToken, ^{ /* ... */ });
}
The Google Objective-C style guide says:
http://google.github.io/styleguide/objcguide.html#common-variable-names
> File scope or global variables (as opposed to constants) declared
> outside the scope of a method or function should be rare, and should
> have the prefix g.
which is meant to insinuate that static variables inside a method or
function don't need a special name.
Test Plan: `make -j12 check-clang-tools`
Reviewers: Wizard, hokein, klimek
Reviewed By: Wizard
Subscribers: xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D41789
llvm-svn: 321914
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:
They are not locally const qualified so they weren't classified as
constants by the readability-identifier-naming check.
Reviewers: alexfh
Reviewed By: alexfh
Subscribers: klimek, cfe-commits, xazax.hun
Patch by Beren Minor!
Differential Revision: https://reviews.llvm.org/D39363
llvm-svn: 320406
We currently use target_link_libraries without an explicit scope
specifier (INTERFACE, PRIVATE or PUBLIC) when linking executables.
Dependencies added in this way apply to both the target and its
dependencies, i.e. they become part of the executable's link interface
and are transitive.
Transitive dependencies generally don't make sense for executables,
since you wouldn't normally be linking against an executable. This also
causes issues for generating install export files when using
LLVM_DISTRIBUTION_COMPONENTS. For example, clang has a lot of LLVM
library dependencies, which are currently added as interface
dependencies. If clang is in the distribution components but the LLVM
libraries it depends on aren't (which is a perfectly legitimate use case
if the LLVM libraries are being built static and there are therefore no
run-time dependencies on them), CMake will complain about the LLVM
libraries not being in export set when attempting to generate the
install export file for clang. This is reasonable behavior on CMake's
part, and the right thing is for LLVM's build system to explicitly use
PRIVATE dependencies for executables.
Unfortunately, CMake doesn't allow you to mix and match the keyword and
non-keyword target_link_libraries signatures for a single target; i.e.,
if a single call to target_link_libraries for a particular target uses
one of the INTERFACE, PRIVATE, or PUBLIC keywords, all other calls must
also be updated to use those keywords. This means we must do this change
in a single shot. I also fully expect to have missed some instances; I
tested by enabling all the projects in the monorepo (except dragonegg),
and configuring both with and without shared libraries, on both Darwin
and Linux, but I'm planning to rely on the buildbots for other
configurations (since it should be pretty easy to fix those).
Even after this change, we still have a lot of target_link_libraries
calls that don't specify a scope keyword, mostly for shared libraries.
I'm thinking about addressing those in a follow-up, but that's a
separate change IMO.
Differential Revision: https://reviews.llvm.org/D40823
llvm-svn: 319840
Yan Zhang