Otherwise we don't warn on a struct containing a single public int, but
we warn on a struct containing a single public std::string, which is
inconsistent.
llvm-svn: 351686
to reflect the new license.
We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.
llvm-svn: 351636
Summary:
The underlying issue is fixed in https://reviews.llvm.org/D56444
and this test ensures the issue does not creep back into our
code-base.
Reviewers: alexfh, aaron.ballman, hokein, hwright
Reviewed By: aaron.ballman
Subscribers: xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D56918
llvm-svn: 351569
Summary:
Previously, we weren't recognizing these as smart pointers and thus
weren't allowing non-dereference accesses as we should -- see new test
cases which fail without the fix.
Reviewers: alexfh, hokein, aaron.ballman, JonasToth
Reviewed By: JonasToth
Subscribers: xazax.hun, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D56585
llvm-svn: 351303
Summary: Adds a checker to clang-tidy to warn when a non void const member function, taking only parameters passed by value or const reference could be marked as '[[nodiscard]]'
Patch by MyDeveloperDay.
Reviewers: alexfh, stephenkelly, curdeius, aaron.ballman, hokein, JonasToth
Reviewed By: curdeius, JonasToth
Subscribers: Eugene.Zelenko, lefticus, lebedev.ri, mgorny, xazax.hun, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D55433
llvm-svn: 350760
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.
Reviewed By: JonasToth, lebedev.ri
Differential Revision: https://reviews.llvm.org/D56025
llvm-svn: 350056
Summary:
Previously, we'd only match on literal floating or integral zeroes, but I've now also learned that some users spell that value as int{0} or float{0}, which also need to be matched.
Differential Revision: https://reviews.llvm.org/D56012
llvm-svn: 349953
Summary:
This change relaxes the requirements on the utility
`rewriteExprFromNumberToDuration` function, and introduces new checking
inside of the `abseil-duration-comparison` check to allow macro argument
expression transformation.
Differential Revision: https://reviews.llvm.org/D55784
llvm-svn: 349636
Summary:
The diagnostics from google-objc-function-naming check will be more
actionable if they provide a brief description of the requirements from
the Google Objective-C style guide. The more descriptive diagnostics may
help clarify that functions in the global namespace must have an
appropriate prefix followed by Pascal case (engineers working previously
with static functions might not immediately understand the different
requirements of static and non-static functions).
Test Notes:
Verified against the clang-tidy tests.
Reviewers: benhamilton, aaron.ballman
Reviewed By: benhamilton
Subscribers: MyDeveloperDay, xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D55482
llvm-svn: 349123
Summary:
This check uses the context of a subtraction expression as well as knowledge
about the Abseil Time types, to infer the type of the second operand of some
subtraction expressions in Duration conversions. For example:
absl::ToDoubleSeconds(duration) - foo
can become
absl::ToDoubleSeconds(duration - absl::Seconds(foo))
This ensures that time calculations are done in the proper domain, and also
makes it easier to further deduce the types of the second operands to these
expressions.
Reviewed By: JonasToth
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D55245
llvm-svn: 349073
Summary: Several tests re-implement these same prototypes (differently), so we can put them in a common location.
Patch by hwright.
Reviewers: JonasToth
Reviewed By: JonasToth
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D55540
llvm-svn: 348840
Patch by Alex Strelnikov.
Reviewed as D53830
Introduce a new check to upgrade user code based on upcoming API breaking changes to absl::Duration.
The check finds calls to arithmetic operators and factory functions for absl::Duration that rely on
an implicit user defined conversion to int64_t. These cases will no longer compile after proposed
changes are released. Suggested fixes explicitly cast the argument int64_t.
llvm-svn: 348633
Summary:
The intention is to make the tools replaying compilations from 'compile_commands.json'
(clang-tidy, clangd, etc.) find the same standard library as the original compiler
specified in 'compile_commands.json'.
Previously, the library detection logic was in the frontend (InitHeaderSearch.cpp) and relied
on the value of resource dir as an approximation of the compiler install dir. The new logic
uses the actual compiler install dir and is performed in the driver. This is consistent with
the C++ standard library detection on other platforms and allows to override the resource dir
in the tools using the compile_commands.json without altering the
standard library detection mechanism. The tools have to override the resource dir to make sure
they use a consistent version of the builtin headers.
There is still logic in InitHeaderSearch that attemps to add the absolute includes for the
the C++ standard library, so we keep passing the -stdlib=libc++ from the driver to the frontend
via cc1 args to avoid breaking that. In the long run, we should move this logic to the driver too,
but it could potentially break the library detection on other systems, so we don't tackle it in this
patch to keep its scope manageable.
This is a second attempt to fix the issue, first one was commited in r346652 and reverted in r346675.
The original fix relied on an ad-hoc propagation (bypassing the cc1 flags) of the install dir from the
driver to the frontend's HeaderSearchOptions. Unsurpisingly, the propagation was incomplete, it broke
the libc++ detection in clang itself, which caused LLDB tests to break.
The LLDB tests pass with new fix.
Reviewers: JDevlieghere, arphaman, EricWF
Reviewed By: arphaman
Subscribers: mclow.lists, ldionne, dexonsmith, ioeric, christof, kadircet, cfe-commits
Differential Revision: https://reviews.llvm.org/D54630
llvm-svn: 348365
Summary:
Implement a check for detecting if/else if/else chains where two or more
branches are Type I clones of each other (that is, they contain identical code)
and for detecting switch statements where two or more consecutive branches are
Type I clones of each other.
Patch by donat.nagy.
Reviewers: alexfh, hokein, aaron.ballman, JonasToth
Reviewed By: JonasToth
Subscribers: MTC, lebedev.ri, whisperity, xazax.hun, Eugene.Zelenko, mgorny, rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D54757
llvm-svn: 348343
Summary:
bugprone-misplaced-widening-cast check
used to give a false warning to the
following example.
enum DaysEnum{
MON = 0,
TUE = 1
};
day = (DaysEnum)(day + 1);
//warning: either cast from 'int' to 'DaysEnum' is ineffective...
But i think int to enum cast is not widening neither ineffective.
Patch by dkrupp.
Reviewers: JonasToth, alexfh
Reviewed By: alexfh
Subscribers: rnkovacs, Szelethus, gamesh411, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D55255
llvm-svn: 348341
Summary:
§1 Description
This changes the objc-property-declaration check to allow arbitrary acronyms and initialisms instead of using whitelisted acronyms. In Objective-C it is relatively common to use project prefixes in property names for the purposes of disambiguation. For example, the CIColor¹ and CGColor² properties on UIColor both represent symbol prefixes being used in proeprty names outside of Apple's accepted acronyms³. The union of Apple's accepted acronyms and all symbol prefixes that might be used for disambiguation in property declarations effectively allows for any arbitrary sequence of capital alphanumeric characters to be acceptable in property declarations. This change updates the check accordingly.
The test variants with custom configurations are deleted as part of this change because their configurations no longer impact behavior. The acronym configurations are currently preserved for backwards compatibility of check configuration.
[1] https://developer.apple.com/documentation/uikit/uicolor/1621951-cicolor?language=objc
[2] https://developer.apple.com/documentation/uikit/uicolor/1621954-cgcolor?language=objc
[3] https://developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CodingGuidelines/Articles/APIAbbreviations.html#//apple_ref/doc/uid/20001285-BCIHCGAE
§2 Test Notes
Changes verified by:
• Running clang-tidy unit tests.
• Used check_clang_tidy.py to verify expected output of processing objc-property-declaration.m
Reviewers: benhamilton, Wizard
Reviewed By: benhamilton
Subscribers: jfb, cfe-commits
Differential Revision: https://reviews.llvm.org/D51832
llvm-svn: 348331
Summary: The google-objc-function-naming check applies to functions that are not namespaced and should not be applied to C++ member functions. Such function declarations should be ignored by the check to avoid false positives in Objective-C++ sources.
Reviewers: benhamilton, aaron.ballman
Reviewed By: aaron.ballman
Subscribers: xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D55101
llvm-svn: 348317
Summary:
This check finds instances where Duration values are being converted to a numeric value in a comparison expression, and suggests that the conversion happen on the other side of the expression to a Duration. See documentation for examples.
This also shuffles some code around so that the new check may perform in sone step simplifications also caught by other checks.
Compilation is unbroken, because the hash-function is now directly
specified for std::unordered_map, as 'enum class' does not compile as
key (seamingly only on some compilers).
Patch by hwright.
Reviewers: aaron.ballman, JonasToth, alexfh, hokein
Reviewed By: JonasToth
Subscribers: sammccall, Eugene.Zelenko, xazax.hun, cfe-commits, mgorny
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D54737
llvm-svn: 348169
Summary:
This check finds instances where Duration values are being converted to a numeric value in a comparison expression, and suggests that the conversion happen on the other side of the expression to a Duration. See documentation for examples.
This also shuffles some code around so that the new check may perform in sone step simplifications also caught by other checks.
Patch by hwright.
Reviewers: aaron.ballman, JonasToth, alexfh, hokein
Reviewed By: JonasToth
Subscribers: sammccall, Eugene.Zelenko, xazax.hun, cfe-commits, mgorny
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D54737
llvm-svn: 348161
This check is about preventing exceptions from being thrown before main() executes, and assigning a lambda (rather than calling it) to a global object cannot throw any exceptions.
llvm-svn: 347761
If a variable is declared constexpr then its initializer needs to be a constant expression, and thus, cannot throw. This check is about not throwing exceptions before main() runs, and so it doesn't apply if the initializer cannot throw. This silences the diagnostic when initializing a constexpr variable and fixes PR35457.
llvm-svn: 347745
Summary: There is no ambiguity / information loss in this conversion
Reviewers: alexfh, aaron.ballman, hokein
Reviewed By: alexfh
Subscribers: xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D54941
llvm-svn: 347671
When a warning is issued in a template instantiation, the check would previously
use template arguments in a note, which would result in inconsistent or
duplicate warnings (depending on how deduplication was done). This patch removes
template arguments from the note.
llvm-svn: 347652
Summary: The fix for `auto` new expression is illegal.
Reviewers: aaron.ballman
Subscribers: xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D54832
llvm-svn: 347551
Summary:
The fix for aggregate initialization (`std::make_unique<Foo>(Foo {1, 2})` needs
to see Foo copy constructor, otherwise we will have a compiler error. So we
only emit the check warning.
Reviewers: JonasToth, aaron.ballman
Subscribers: xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D54745
llvm-svn: 347537
The test I'm adding passes without the change due to the deduplication logic in
ClangTidyDiagnosticConsumer::take(). However this bug manifests in our internal
integration with clang-tidy.
I've verified the fix by locally changing LessClangTidyError to consider
replacements.
llvm-svn: 347470
Summary:
Currently the smart_ptr check (modernize-make-unique) generates the
fixes that cannot compile for cases like below -- because brace list can
not be deduced in `make_unique`.
```
struct Bar { int a, b; };
struct Foo { Foo(Bar); };
auto foo = std::unique_ptr<Foo>(new Foo({1, 2}));
```
Reviewers: aaron.ballman
Subscribers: xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D54704
llvm-svn: 347315
Summary:
§1 Description
This check finds function names in function declarations in Objective-C files that do not follow the naming pattern described in the Google Objective-C Style Guide. Function names should be in UpperCamelCase and functions that are not of static storage class should have an appropriate prefix as described in the Google Objective-C Style Guide. The function `main` is a notable exception. Function declarations in expansions in system headers are ignored.
Example conforming function definitions:
```
static bool IsPositive(int i) { return i > 0; }
static bool ABIsPositive(int i) { return i > 0; }
bool ABIsNegative(int i) { return i < 0; }
```
A fixit hint is generated for functions of static storage class but otherwise the check does not generate a fixit hint because an appropriate prefix for the function cannot be determined.
§2 Test Notes
* Verified clang-tidy tests pass successfully.
* Used check_clang_tidy.py to verify expected output of processing google-objc-function-naming.m
Reviewers: benhamilton, hokein, Wizard, aaron.ballman
Reviewed By: benhamilton
Subscribers: Eugene.Zelenko, mgorny, xazax.hun, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D51575
llvm-svn: 347132
Summary:
[[ https://bugs.llvm.org/show_bug.cgi?id=39224 | PR39224 ]]
As discussed, we can't always do the transform automatically due to that array-to-pointer decay of C array.
In order to detect whether we can do said transform, we'd need to be able to see all usages of said array,
which is, i would say, rather impossible if e.g. it is in the header.
Thus right now no fixit exists.
Exceptions: `extern "C"` code.
References:
* [[ https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es27-use-stdarray-or-stack_array-for-arrays-on-the-stack | CPPCG ES.27: Use std::array or stack_array for arrays on the stack ]]
* [[ https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#slcon1-prefer-using-stl-array-or-vector-instead-of-a-c-array | CPPCG SL.con.1: Prefer using STL array or vector instead of a C array ]]
* HICPP `4.1.1 Ensure that a function argument does not undergo an array-to-pointer conversion`
* MISRA `5-2-12 An identifier with array type passed as a function argument shall not decay to a pointer`
Reviewers: aaron.ballman, JonasToth, alexfh, hokein, xazax.hun
Reviewed By: JonasToth
Subscribers: Eugene.Zelenko, mgorny, rnkovacs, cfe-commits
Tags: #clang-tools-extra
Differential Revision: https://reviews.llvm.org/D53771
llvm-svn: 346835
Miklos Vajna