Previously we would call getAsTemplate() when kind == TemplateExpansion,
which triggers an assertion. The call is now replaced with
getAsTemplateOrTemplatePattern(), which is exactly the same as
getAsTemplate(), except it allows calls when kind == TemplateExpansion.
No change in behavior for no-assert builds.
Differential Revision: https://reviews.llvm.org/D111648
The list of checked functions was incomplete in the description.
Reviewed By: aaron.ballman, steakhal
Differential Revision: https://reviews.llvm.org/D111623
This requirement was introduced in the C++ Core guidelines in 2016:
1894380d0a
Then clang-tidy got updated to comply with the rule.
However in 2019 this decision was reverted:
5fdfb20b76
Therefore we need to apply the correct configuration to
clang-tidy again.
This also makes this cppcoreguidelines check consistent
with the other 2 alias checks: hicpp-use-override and
modernize-use-override.
Additionally, add another RUN line to the unit test,
to make sure cppcoreguidelines-explicit-virtual-functions
is tested.
As described on D111049, we're trying to remove the <string> dependency from error handling and replace uses of report_fatal_error(const std::string&) with the Twine() variant which can be forward declared.
Previously, the code in add_new_check.py that looks for fixit keywords in check source files when generating list.rst assumed that the script would only be called from its own path. That means it doesn't find any source files for the checks it's attempting to scan for, and it defaults to writing out nothing in the "Offers fixes" column for all checks. Other parts of add_new_check.py work from other paths, just not this part.
After this fix, add_new_check.py's "offers fixes" column generation for list.rst will be consistent regardless of what path it's called from by using the caller path that's deduced elsewhere already from sys.argv[0].
Reviewed By: kbobyrev
Differential Revision: https://reviews.llvm.org/D110600
Addresses https://github.com/clangd/clangd/issues/881
Includes refs of base class method in refs of derived class method.
Previously we reported base class method's refs only for decl of derived
class method. Ideally this should work for all usages of derived class method.
Related patch:
fbeff2ec2b.
Differential Revision: https://reviews.llvm.org/D111039
- Support enums in C and ObjC as their
AST representations differ slightly.
- Add support for typedef'ed enums.
Differential Revision: https://reviews.llvm.org/D110954
Stop using APInt constructors and methods that were soft-deprecated in
D109483. This fixes all the uses I found in clang.
Differential Revision: https://reviews.llvm.org/D110808
References to fields inside anon structs contain an implicit children
for the container, which has the same SourceLocation with the field.
This was resulting in SelectionTree always picking the anon-struct rather than
the field as the selection.
This patch prevents that by claiming the range for the field early.
https://github.com/clangd/clangd/issues/877.
Differential Revision: https://reviews.llvm.org/D110825
We can directly use cast<> instead of separate dyn_cast<> with assertions as cast<> will perform this for us.
Similarly we can replace a if(isa<>)+cast<>/dyn_cast<> with if(dyn_cast<>)
Add support for NOLINTBEGIN ... NOLINTEND comments to suppress
clang-tidy warnings over multiple lines. All lines between the "begin"
and "end" markers are suppressed.
Example:
// NOLINTBEGIN(some-check)
<Code with warnings to be suppressed, line 1>
<Code with warnings to be suppressed, line 2>
<Code with warnings to be suppressed, line 3>
// NOLINTEND(some-check)
Follows similar syntax as the NOLINT and NOLINTNEXTLINE comments
that are already implemented, i.e. allows multiple checks to be provided
in parentheses; suppresses all checks if the parentheses are omitted,
etc.
If the comments are misused, e.g. using a NOLINTBEGIN but not
terminating it with a NOLINTEND, a clang-tidy-nolint diagnostic
message pointing to the misuse is generated.
As part of implementing this feature, the following bugs were fixed in
existing code:
IsNOLINTFound(): IsNOLINTFound("NOLINT", Str) returns true when Str is
"NOLINTNEXTLINE". This is because the textual search finds NOLINT as
the stem of NOLINTNEXTLINE.
LineIsMarkedWithNOLINT(): NOLINTNEXTLINEs on the very first line of a
file are ignored. This is due to rsplit('\n\').second returning a blank
string when there are no more newline chars to split on.
Fixes https://bugs.llvm.org/show_bug.cgi?id=51790. The check triggers
incorrectly with non-type template parameters.
A bisect determined that the bug was introduced here:
ea2225a10b
Unfortunately that patch can no longer be reverted on top of the main
branch, so add a fix instead. Add a unit test to avoid regression in
the future.
At most one variant member of a union may have a default member
initializer. The case of anonymous records with multiple levels of
nesting like the following also needs to meet this rule. The original
logic is to horizontally obtain all the member variables in a record
that need to be initialized and then filter to the variables that need
to be fixed. Obviously, it is impossible to correctly initialize the
desired variables according to the nesting relationship.
See Example 3 in class.union
union U {
U() {}
int x; // int x{};
union {
int k; // int k{}; <== wrong fix
};
union {
int z; // int z{}; <== wrong fix
int y;
};
};
Xcode uses `#pragma mark -` to draw a divider in the outline view
and `#pragma mark Note` to add `Note` in the outline view. For more
information, see https://nshipster.com/pragma/.
Since the LSP spec doesn't contain dividers for the symbol outline,
instead we treat `#pragma mark -` as a group with children - the
decls that come after it, implicitly terminating when the symbol's
parent ends.
The following code:
```
@implementation MyClass
- (id)init {}
- (int)foo;
@end
```
Would give an outline like
```
MyClass
> Overrides
> init
> Public Accessors
> foo
```
Differential Revision: https://reviews.llvm.org/D105904
That macro was being defined but not used anywhere in libc++, so it
must be safe to remove it.
As a fly-by fix, also remove mentions of this macro in other places
in LLVM, to make sure they were not depending on the value defined in
libc++.
Differential Revision: https://reviews.llvm.org/D110289
Don't create a useless functional patch with only filename in it when
there is only include directives to be patched but they're not
requested.
Differential Revision: https://reviews.llvm.org/D109880
Don't install clang-tidy checks and IncludeFixer or process clang diags
when they're going to be dropped. Also disables analysis for some
warnings completely.
Differential Revision: https://reviews.llvm.org/D109884
Fixes https://github.com/clangd/clangd/issues/819
SourceLocation of macros change when a header file is included above it. This is not checked when creating a PreamblePatch, resulting in reusing previously built preamble with an incorrect source location for the macro in the example test case.
This patch stores the SourceLocation in the struct TextualPPDirective so that it gets checked when comparing old vs new preambles.
Also creates a preamble patch for code completion parsing so that clangd does not crash when following the example test case with a large file.
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D108045
This reverts commit 626586fc25.
Tweak the test for Windows. Windows defaults to delayed template
parsing, which resulted in the main template definition not registering
the test on Windows. Process the file with the additional
`-fno-delayed-template-parsing` flag to change the default beahviour.
Additionally, add an extra check for the fix it and use a more robust
test to ensure that the value is always evaluated.
Differential Revision: https://reviews.llvm.org/D108893
This reverts commit 76dc8ac36d.
Restore the change. The test had an incorrect negative from testing.
The test is expected to trigger a failure as mentioned in the review
comments. This corrects the test and should resolve the failure.
This introduces a new check, readability-containter-data-pointer. This
check is meant to catch the cases where the user may be trying to
materialize the data pointer by taking the address of the 0-th member of
a container. With C++11 or newer, the `data` member should be used for
this. This provides the following benefits:
- `.data()` is easier to read than `&[0]`
- it avoids an unnecessary re-materialization of the pointer
* this doesn't matter in the case of optimized code, but in the case
of unoptimized code, this will be visible
- it avoids a potential invalid memory de-reference caused by the
indexing when the container is empty (in debug mode, clang will
normally optimize away the re-materialization in optimized builds).
The small potential behavioural change raises the question of where the
check should belong. A reasoning of defense in depth applies here, and
this does an unchecked conversion, with the assumption that users can
use the static analyzer to catch cases where we can statically identify
an invalid memory de-reference. For the cases where the static analysis
is unable to prove the size of the container, UBSan can be used to track
the invalid access.
Special thanks to Aaron Ballmann for the discussion on whether this
check would be useful and where to place it.
This also partially resolves PR26817!
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D108893
Even though they're implemented via typedefs, we typically
want to treat them like keywords.
We could add hover information / xrefs, but it's very unlikely
to provide any value.
Differential Revision: https://reviews.llvm.org/D108556
Rename methods to clearly signal when they only deal with ASCII,
simplify the parsing of identifier, and use start/continue instead of
head/body for consistency with Unicode terminology.
As of this commit:
https://github.com/llvm/llvm-project/commit/307b1fdd
If either of those scripts are invoked with python 2, neither works due to:
"TypeError: write() argument 1 must be unicode, not str"
And if rename_check.py is invoked with python 3:
"ValueError: binary mode doesn't take an encoding argument"
(referring to `with io.open(filename, 'wb', encoding='utf8') as f:`), and
Another issue in rename_check.py in python 2:
"TypeError: list object is not an iterator"
(referring to `next(filter( ... os.listdir(old_module_path)))`)
(so, rename_check doesn't work with either 2 or 3, and add_new_check
doesn't work with 2, but does work with 3)
I ran these steps to test both python versions:
(manually - appears to be the "status quo" for these files)
python3 clang-tools-extra/clang-tidy/add_new_check.py readability ggggg
python3 clang-tools-extra/clang-tidy/rename_check.py readability-ggggg readability-hhhhh
git checkout HEAD -- clang-tools-extra/clang-tidy/readability/CMakeLists.txt clang-tools-extra/clang-tidy/readability/ReadabilityTidyModule.cpp clang-tools-extra/docs/ReleaseNotes.rst clang-tools-extra/docs/clang-tidy/checks/list.rst
rm -f clang-tools-extra/clang-tidy/readability/GggggCheck.cpp clang-tools-extra/clang-tidy/readability/GggggCheck.h clang-tools-extra/docs/clang-tidy/checks/readability-ggggg.rst clang-tools-extra/test/clang-tidy/checkers/readability-ggggg.cpp clang-tools-extra/clang-tidy/readability/HhhhhCheck.cpp clang-tools-extra/clang-tidy/readability/HhhhhCheck.h clang-tools-extra/docs/clang-tidy/checks/readability-hhhhh.rst
python2 clang-tools-extra/clang-tidy/add_new_check.py readability ggggg
python2 clang-tools-extra/clang-tidy/rename_check.py readability-ggggg readability-hhhhh
git checkout HEAD -- clang-tools-extra/clang-tidy/readability/CMakeLists.txt clang-tools-extra/clang-tidy/readability/ReadabilityTidyModule.cpp clang-tools-extra/docs/ReleaseNotes.rst clang-tools-extra/docs/clang-tidy/checks/list.rst
rm -f clang-tools-extra/clang-tidy/readability/GggggCheck.cpp clang-tools-extra/clang-tidy/readability/GggggCheck.h clang-tools-extra/docs/clang-tidy/checks/readability-ggggg.rst clang-tools-extra/test/clang-tidy/checkers/readability-ggggg.cpp clang-tools-extra/clang-tidy/readability/HhhhhCheck.cpp clang-tools-extra/clang-tidy/readability/HhhhhCheck.h clang-tools-extra/docs/clang-tidy/checks/readability-hhhhh.rst
Reviewed By: kbobyrev
Differential Revision: https://reviews.llvm.org/D109127
Finds base classes and structs whose destructor is neither public and
virtual nor protected and non-virtual.
A base class's destructor should be specified in one of these ways to
prevent undefined behaviour.
Fixes are available for user-declared and implicit destructors that are
either public and non-virtual or protected and virtual.
This check implements C.35 [1] from the CppCoreGuidelines.
Reviewed By: aaron.ballman, njames93
Differential Revision: http://reviews.llvm.org/D102325
[1]: http://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rc-dtor-virtual
Low-level code may occasionally deal with direct access by concrete addresses
such as 0x1234. Values at these addresses act like globals: they can change
at any time. They typically wear volatile qualifiers.
Suppress all warnings on loops with conditions that involve casting anything to
a pointer-to-...-pointer-to-volatile type.
The closely related bugprone-redundant-branch-condition check
doesn't seem to be affected. Add a test just in case.
Differential Revision: https://reviews.llvm.org/D108808
This reverts commit 2fbd254aa4, which broke the libc++ CI. I'm reverting
to get things stable again until we've figured out a way forward.
Differential Revision: https://reviews.llvm.org/D108696
This helps improve the syntax highlighting for Objective-C code,
although it currently doesn't work well in VS Code with
methods/properties/ivars since we don't currently include the proper
decl context (e.g. class).
Differential Revision: https://reviews.llvm.org/D108584
Summary: Now in libcxx and clang, all the coroutine components are
defined in std::experimental namespace.
And now the coroutine TS is merged into C++20. So in the working draft
like N4892, we could find the coroutine components is defined in std
namespace instead of std::experimental namespace.
And the coroutine support in clang seems to be relatively stable. So I
think it may be suitable to move the coroutine component into the
experiment namespace now.
But move the coroutine component into the std namespace may be an break
change. So I planned to split this change into two patch. One in clang
and other in libcxx.
This patch would make clang lookup coroutine_traits in std namespace
first. For the compatibility consideration, clang would lookup in
std::experimental namespace if it can't find definitions in std
namespace and emit a warning in this case. So the existing codes
wouldn't be break after update compiler.
Test Plan: check-clang, check-libcxx
Reviewed By: lxfind
Differential Revision: https://reviews.llvm.org/D108696
I discovered this quirk when working on some DWARF - AST printing prints
type template parameters fully qualified, but printed template template
parameters the way they were written syntactically, or wholely
unqualified - instead, we should print them consistently with the way we
print type template parameters: fully qualified.
The one place this got weird was for partial specializations like in
ast-print-temp-class.cpp - hence the need for checking for
TemplateNameDependenceScope::DependentInstantiation template template
parameters. (not 100% sure that's the right solution to that, though -
open to ideas)
Differential Revision: https://reviews.llvm.org/D108794
As identified by @RKSimon, there was a missing comma in the default
value for the "ignored parameter type suffixes" array, resulting in
bogus concatenation of two elements.
This is the first patch in an ongoing attempt of Include Cleaner: unused/missing
headere diagnostics, an IWYU-like functionality implementation for clangd. The
work is split into (mostly) distinct and parallelizable pieces:
- Finding all referenced locations (this patch).
- Finding all referenced locations of macros.
- Building IncludeGraph and marking headers as unused, used and directly used.
- Making use of the introduced library and add an option to use in clangd.
---
* Adding support for standard library headers (possibly through mapping
genfiles).
Based on https://reviews.llvm.org/D100540.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D105426
https://bugs.llvm.org/show_bug.cgi?id=50069
When clang-tidy sees:
```
if (true) [[unlikely]] {
...
}
```
It thinks the braces are missing and add them again.
```
if (true) { [[unlikely]] {
...
}
}
```
This revision aims to prevent that incorrect code generation
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D105479
The overload of the constructor will repeatedly fix the member variables that need to be initialized.
Removed the duplicate '{}'.
```
struct A {
A() {}
A(int) {}
int _var; // int _var{}{}; <-- wrong fix
};
```
Reviewed By: aaron.ballman
Differential Revision: https://reviews.llvm.org/D107641
This happens in createInvocationWithCommandLine but only clangd currently passes
ShouldRecoverOnErorrs (sic).
One cause of this (with correct command) is several -arch arguments for mac
multi-arch support.
Fixes https://github.com/clangd/clangd/issues/827
Differential Revision: https://reviews.llvm.org/D107632
... to the one of signature hints.
In particular, completion items now also carry annotations, which client
code might be interested in.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D107365
It's quite useful to be able to hover over an #include and see the full
path to the header file.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D107137
Only the bare name is completed, with no args.
For args to be useful we need arg names. These *are* in the tablegen but
not currently emitted in usable form, so left this as future work.
C++11, C2x, GNU, declspec, MS syntax is supported, with the appropriate
spellings of attributes suggested.
`#pragma clang attribute` is supported but not terribly useful as we
only reach completion if parens are balanced (i.e. the line is not truncated)
There's no filtering of which attributes might make sense in this
grammatical context (e.g. attached to a function). In code-completion context
this is hard to do, and will only work in few cases :-(
There's also no filtering by langopts: this is because currently the
only way of checking is to try to produce diagnostics, which requires a
valid ParsedAttr which is hard to get.
This should be fairly simple to fix but requires some tablegen changes
to expose the logic without the side-effect.
Differential Revision: https://reviews.llvm.org/D107696
Add a check for enforcing minimum length for variable names. A default
minimum length of three characters is applied to regular variables
(including function parameters). Loop counters and exception variables
have a minimum of two characters. Additionally, the 'i', 'j' and 'k'
are accepted as legacy values.
All three sizes, as well as the list of accepted legacy loop counter
names are configurable.
The patch in http://reviews.llvm.org/D106431 landed in commit
4a097efe77 to the main branch.
However, this patch was also backported to upcoming release 13.0.0 in
commit 8dcdfc0de84f60b5b4af97ac5b357881af55bc6e, which makes this entry
in the release notes **NOT** a new thing for the purposes of 14.0.0.
Some files still contained the old University of Illinois Open Source
Licence header. This patch replaces that with the Apache 2 with LLVM
Exception licence.
Differential Revision: https://reviews.llvm.org/D107528
std::string, std::string_view, and absl::string_view all have a three-parameter version of find()
which has a "count" (or "n") paremeter limiting the size of the substring to search. We don't want
to propose changing to absl::StrContains in those cases. This change fixes that and adds unit tests
to confirm.
Reviewed By: ymandel
Differential Revision: https://reviews.llvm.org/D107837
Xcode uses `#pragma mark -` to draw a divider in the outline view
and `#pragma mark Note` to add `Note` in the outline view. For more
information, see https://nshipster.com/pragma/.
Since the LSP spec doesn't contain dividers for the symbol outline,
instead we treat `#pragma mark -` as a group with children - the
decls that come after it, implicitly terminating when the symbol's
parent ends.
The following code:
```
@implementation MyClass
- (id)init {}
- (int)foo;
@end
```
Would give an outline like
```
MyClass
> Overrides
> init
> Public Accessors
> foo
```
Differential Revision: https://reviews.llvm.org/D105904
These aren't terribly common, but we currently mishandle them badly.
Not only do we not recogize the attributes themselves, but we often end up
selecting some node other than the parent (because source ranges aren't accurate
in the presence of attributes).
Differential Revision: https://reviews.llvm.org/D89785
We already strip all the inputs provided without `--`, this patch also
handles the cases with `--`.
Differential Revision: https://reviews.llvm.org/D107637
This patch strips all the arch options in case of multiple ones. As it
results in multiple compiler jobs, which clangd cannot handle.
It doesn't pick any over the others as it is unclear which one the user wants
and defaulting to host architecture seems less surprising. Users also have the
ability to explicitly specify the architecture they want via clangd config
files.
Fixes https://github.com/clangd/clangd/issues/827.
Differential Revision: https://reviews.llvm.org/D107634
This is needed for clients that want to highlight virtual functions
differently.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D107145
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
Adam Czachorowski