These are identified by misc-include-cleaner. I've filtered out those
that break builds. Also, I'm staying away from llvm-config.h,
config.h, and Compiler.h, which likely cause platform- or
compiler-specific build failures.
I'm planning to remove StringRef::equals in favor of
StringRef::operator==.
- StringRef::operator==/!= outnumber StringRef::equals by a factor of
276 under llvm-project/ in terms of their usage.
- The elimination of StringRef::equals brings StringRef closer to
std::string_view, which has operator== but not equals.
- S == "foo" is more readable than S.equals("foo"), especially for
!Long.Expression.equals("str") vs Long.Expression != "str".
The handling of renaming failures and multiple usages related to those
failures is currently spread over several functions. Identifying the
failure NamedDecl for a given usage is also duplicated, once when
creating failures and again when identify usages. There are currently
two ways to a failed NamedDecl from a usage: use the canonical decl or
use the overridden method. With new methods about to be added, a cleanup
was in order.
The data flow is simplified as follows:
* The visitor always forwards NamedDecls to addUsage(NamedDecl).
* addUsage(NamedDecl) determines the failed NamedDecl and determines
potential new names based on that failure. Usages are registered using
addUsage(NamingCheckId).
* addUsage(NamingCheckId) is now protected and its single responsibility
is maintaining the integrity of the failure/usage map.
Fix handling of Hungarian Prefix when configured to LowerCase.
Warnings no longer will be emited for names that already match
this style.
Fixes: #80268
Summary:
Some build systems create symlinks in a temporary build directory for
headers in the source tree for isolation purposes. These symlinks
prevent `readability-identifier-naming` detecting issues and applying
fixes. Without this fix clang-tidy is checking .clang-tidy config file
in a temporary directory instead of source source location.
Test Plan: check-clang-tools
Currently, fields in anonymous records are treated as normal record
members during naming style check. This can be undesirable in certain
situations since these fields are used just like names in their
enclosing scopes:
```c++
class Foo {
union {
int iv_; // warning: invalid case style for public member 'iv_'
float fv_; // warning: invalid case style for public member 'fv_'
};
};
```
`iv_` and `fv_` are used in the code like private members of `Foo` but
their naming style comes from rules for public members.
This PR changes this behavior. It adds a new option
`CheckAnonFieldInParent` to `readability-identifier-naming`. When set to
`true`, fields in anonymous records will be treated as names in their
enclosing scopes when checking name styles. Specifically:
- If the anonymous record is defined within the file scope or in a
namespace scope, treat its fields as global variables when checking name
styles;
- If the anonymous record is defined within a function, treat its fields
as local variables when checking name styles;
- If the anonymous record is defined within a non-anonymous record,
treat its fields as non-static record members when checking name styles.
This patch replaces uses of StringRef::{starts,ends}with with
StringRef::{starts,ends}_with for consistency with
std::{string,string_view}::{starts,ends}_with in C++20.
I'm planning to deprecate and eventually remove
StringRef::{starts,ends}with.
Improves the accuracy of `readability-identifier-naming` for cases
`Camel_Snake_Case` and `camel_Snake_Back`. Prior to this commit, these
cases matched identifiers with **only** a leading upper case letter or
leading lower case letter respectively. Now, uppercase letters can only
appear at the start of an identifier or directly following an
underscore.
---
Currently, the regex for `Camel_Snake_Case` matches any identifier that
starts with a capital letter:
```
^[A-Z]([a-z0-9]*(_[A-Z])?)*
^^^^^^^^^-- underscore + capital letter after the first capital is optional
```
This means that `Camel_Snake_Case` matches other cases - in particular
`CamelCase` and `Leading_upper_snake_case` - which causes clang-tidy to
sometimes not flag incorrect casing. It also matches `UPPER_CASE`, but I
think it's reasonable to consider this a subset of `Camel_Snake_Case`
since some users may prefer e.g. `XML_Parser` to `Xml_Parser`. It's
really easy to accidentally type an identifier that clang-tidy doesn't
catch; all you have to do is omit an underscore or forget to capitalize
a letter. The same problem also applies to `camel_Snake_Back` except
that any identifier starting with a lower case letter matches, so I went
ahead and adjusted its regex too. Fixing it also uncovered a minor error
in an existing test.
In C struct are visible as RecordDecl, not as CXXRecordDecl, this type
of declaration were not supported in this check before. Changing check
to support it. Added tests.
Fixes: #55422
Issue were cased by checking if canonical declaration of record is a
definition. Unfortunately when forward declarations were used, it were
not a definition.
Fixes: #64463
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D157190
When checking a C file, enum tags are of type `int` instead of the enum
type as in C++.
So the checker was using `i` as the prefix for enum tags instead of main
letters of the enum type name (for example `rt` for `enum REV_TYPE`).
This commit fixes this divergence and makes the behavior the same between
C and C++ files.
For example, `enum REV_TYPE { rtRevValid };` won't be reported as badly
named when in a C file. Previously, it would have proposed a rename to
`iRevValid`.
This commit also add a file to test the hungarian notation checker with C
files.
The test file was made from identifier-naming-hungarian-notation.cpp
with C++-only features removed.
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D144912
The CharPrinter is a typo and should have been named CharPointer as it
configures the hungarian notation prefix for char pointers (char*).
As all configuration options within
readability-identifier-naming.HungarianNotation.CString.* were not read
at all in the previous clang-tidy version (fixed in D144431), this option
rename won't break existing users.
A note in release notes is added to let users know these options were
renamed.
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D144790
When reading readability-identifier-naming.HungarianNotation.CString
options, correctly use the type string stored in CStr.second instead of
the option name (CStr.first) as the HNOption.CString map key.
This will make CString options really working and properly parsed by the
checker.
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D144431
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated. The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.
This is part of an effort to migrate from llvm::Optional to
std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
There's many instances in clang tidy checks where owning strings are used when we already have a stable string from the options, so using a StringRef makes much more sense.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D124341
Overriding methods should not get a readability-identifier-naming
warning because the issue can only be fixed in the base class; but the
current check for whether a method is overriding does not take the
override attribute into account.
Differential Revision: https://reviews.llvm.org/D113830
Run clang-tidy on all source files under `clang-tools-extra/clang-tidy`
with `-header-filter=clang-tidy.*` and make suggested corrections.
Differential Revision: https://reviews.llvm.org/D112864
This patch tries to fix command line too long problem on Windows for
https://reviews.llvm.org/D86671.
The command line is too long with check_clang_tidy.py program on Windows,
because the configuration is long for regression test. Fix this issue by
passing the settings in file instead.
Differential Revision: https://reviews.llvm.org/D107325
If a identifier has a correct prefix/suffix but a bad case, the fix won't strip them when computing the correct case, leading to duplication when the are added back.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D98521
The interface served a purpose, but since the ability to emit diagnostics when parsing configuration was added, its become mostly redundant. Emitting the diagnostic and removing the boilerplate is much cleaner.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D97614
Add methods for emitting diagnostics with no location as well as a special diagnostic for configuration errors.
These show up in the errors as [clang-tidy-config].
The reason to use a custom name rather than the check name is to distinguish the error isn't the same category as the check that reported it.
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D91885
This is partly in preparation for an upcoming change that can change the
order in which DeclContext lookup results are presented.
In passing, fix some obvious errors where name lookup's notion of a
"static member function" missed static member function templates, and
where its notion of "same set of declarations" was confused by the same
declarations appearing in a different order.
