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
The encoding used for opening files depends on the OS and might be different
from UTF-8 (e.g. on Windows it can be CP-1252). The documentation files use
UTF-8 and might be incompatible with other encodings. For example, right now
`clang-tools-extra/docs/clang-tidy/checks/abseil-no-internal-dependencies.rst`
has non-ASCII quotes and running `add_new_check.py` fails on Windows, because
it tries to read the file with incompatible encoding.
Use `io.open` for compatibility with both Python 2 and Python 3.
Reviewed By: kbobyrev
Differential Revision: https://reviews.llvm.org/D106792
Happens when DestContext is LinkageSpecDecl and hense CurContext happens to be
both not TagDecl and NamespaceDecl.
Minimal reproducer: trigger define outline in
```
namespace ns {
extern "C" {
typedef int foo;
}
foo Fo^o(int id) { return id; }
}
```
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D107047
FixIt, and add support for initialization check of scoped enum
In C++, the enumeration is never Integer, and the enumeration condition judgment is added to avoid compiling errors when it is initialized to an integer.
Add support for initialization check of scope enum.
As the following case show, clang-tidy will give a wrong automatic fix:
enum Color {Red, Green, Blue};
enum class Gender {Male, Female};
void func() {
Color color; // Color color = 0; <--- fix bug
Gender gender; // <--- no warning
}
Reviewd By: aaron.ballman, whisperity
Differential Revision: http://reviews.llvm.org/D106431
This is a gauage metric that sets particular remote-index instances as
used. It should enable accumulation of multiple streams to see number of clangd
processes making use of remote index, broken down by remote index address.
Differential Revision: https://reviews.llvm.org/D106796
Background-indexing is fine, because it uses GlobalCompilationDatabase
to fetch the compile commands (hence uses CommandMangler), and creates
invocation through buildCompilerInvocation.
Depends on D106639.
Differential Revision: https://reviews.llvm.org/D106669
It is not great to list diag ids by hand, but I don't see any other
solution unless diagnostics are annotated with these explicitly, which is a
bigger change in clang and I am not sure if would be worth it.
Diagnostics handled by this patch is by no means exhaustive, there might be
other checks that don't mention "unused"/"deprecated" in their names. But it
feels like this should be enough to catch common diagnostics and can be extended
over time.
Differential Revision: https://reviews.llvm.org/D107040
Many concepts emulation libraries, such as the one found in Range v3, tend to
use non-type template parameters for the enable_if type expression, due to
their versatility in template functions and constructors containing variadic
template parameter packs.
Unfortunately the bugprone-forwarding-reference-overload check does not
handle non-type template parameters, as was first noted in this bug report:
https://bugs.llvm.org/show_bug.cgi?id=38081
This patch fixes this long standing issue and allows for the check to be suppressed
with the use of a non-type template parameter containing enable_if or enable_if_t in
the type expression, so long as it has a default literal value.
An otherwise unexercised code path related to trying to model
"array-to-pointer decay" resulted in a null pointer dereference crash
when parameters of type "reference to array" were encountered.
Fixes crash report http://bugs.llvm.org/show_bug.cgi?id=50995.
Reviewed By: aaron.ballman
Differential Revision: http://reviews.llvm.org/D106946
Useful in logs to understand issues around some platforms we don't have much
experience with (e.g. m1, mingw)
Differential Revision: https://reviews.llvm.org/D105681
With GCC <6 constructing a function_ref from a free function reference
leads to it referencing a temporary function pointer. If the lifetime of
that temporary is insufficient it can crash.
Fixes https://github.com/clangd/clangd/issues/800
Pushes input for the compile action to the end while separating with a
`--` before applying other manglings. This ensures edits that effect only the
arguments that come after them works, like changing parse language via -x.
Fixes https://github.com/clangd/clangd/issues/555.
Differential Revision: https://reviews.llvm.org/D106527
The original code appears to be OK per the spec, but we've had 3 reports of
crashes with certain unofficial builds of clangd that look a lot like old
compilers (GCC 5.4?) getting lifetime rules wrong.
Fixes https://github.com/clangd/clangd/issues/800
Differential Revision: https://reviews.llvm.org/D106654
Take full advantage of AND's iterator children size estimation: use early reset
in sync() and prevent large overhead. The idea is that the children at the
beginning of the list are smaller and cheaper to advance. Very large children
negate the effect of this performance optimisation and hence should be
advanced only when absolutely necessary. By reducing the number of large
iterators' updates, we increase the performance by a large margin.
This change was tested on a comprehensive query dataset. The performance
boost increases with the average length of the query, on small queries it is
close to 45% but the longer they go the closer it gets to 60% and beyond.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D106528
Make the check handle cases of the "common type" involved in the mix
being non-trivial, e.g. pointers, references, attributes, these things
coming from typedefs, etc.
This results in clearer diagnostics that have more coverage in their
explanation, such as saying `const int &` as common type instead of
`int`.
Reviewed By: aaron.ballman
Differential Revision: http://reviews.llvm.org/D106442
Add string list option of type names analagous to `AllowedTypes` which lets
users specify a list of ExcludedContainerTypes.
Types matching this list will not trigger the check when an expensive variable
is copy initialized from a const accessor method they provide, i.e.:
```
ExcludedContainerTypes = 'ExcludedType'
void foo() {
ExcludedType<ExpensiveToCopy> Container;
const ExpensiveToCopy NecessaryCopy = Container.get();
}
```
Even though an expensive to copy variable is copy initialized the check does not
trigger because the container type is excluded.
This is useful for container types that don't own their data, such as view types
where modification of the returned references in other places cannot be reliably
tracked, or const incorrect types.
Differential Revision: https://reviews.llvm.org/D106173
Reviewed-by: ymandel
This can happen when a template with two parameter types is instantiated with a
single type. The fix would only be valid for this instantiation but fail for
others that rely on an implicit type conversion.
The test cases illustrate when the check should trigger and when not.
Differential Revision: https://reviews.llvm.org/D106011
@vabridgers identified a way to crash the check by running on code that
involve `AttributedType`s. This patch fixes the check to first and
foremost not crash, but also improves the logic handling qualifiers.
If the types contain any additional (not just CVR) qualifiers that are
not the same, they will not be deemed mixable. The logic for CVR-Mixing
and the `QualifiersMix` check option remain unchanged.
Reviewed By: aaron.ballman, vabridgers
Differential Revision: http://reviews.llvm.org/D106361
* Due to the LLVM's JSON library changes (?), FuzzyFindRequest serialization is
no longer valid since arrays are serialized as llvm::json::Array already.
Hence, current implementation creates a nested array.
* YAML format is no longer the default, mention this for the benchmark.
* FIXME is no longer relevant. I ran benchmarks that showed no improvement with
priority_queue years ago.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D106432
This seems to be a more useful behavior for tools that use preambles.
I believe it doesn't affect real compiles: the PCH is only included once
when used, and recursive inclusion of the main-file *within* the PCH
isn't supported in any case.
Differential Revision: https://reviews.llvm.org/D106204
This patch removes a duplicate checks in the top-level comments in `clang-tools-extra/clangd/ParsedAST.h`
Reviewed By: kadircet
Differential Revision: https://reviews.llvm.org/D106227
If a clang-tidy child process exits with a signal then run-clang-tidy will exit
with an error but there is no hint why in the output, since the clang-tidy
doesn't log anything and may not even have had the opportunity to do so
depending on the signal used.
`subprocess.CompletedProcess.returncode` is the negative signal number in this
case.
I hit this in a CI system where the parallelism used exceeded the RAM assigned
to the container causing the OOM killer to SIGKILL clang-tidy processes.
Reviewed By: sylvestre.ledru
Differential Revision: https://reviews.llvm.org/D99081
Finds function calls where the call arguments might be provided in an
incorrect order, based on the comparison (via string metrics) of the
parameter names and the argument names against each other.
A diagnostic is emitted if an argument name is similar to a *different*
parameter than the one currently passed to, and it is sufficiently
dissimilar to the one it **is** passed to currently.
False-positive warnings from this check are useful to indicate bad
naming convention issues, even if a swap isn't necessary.
This check does not generate FixIts.
Originally implemented by @varjujan as his Master's Thesis work.
The check was subsequently taken over by @barancsuk who added type
conformity checks to silence false positive matches.
The work by @whisperity involved driving the check's review and fixing
some more bugs in the process.
Reviewed By: aaron.ballman, alexfh
Differential Revision: http://reviews.llvm.org/D20689
Co-authored-by: János Varjú <varjujanos2@gmail.com>
Co-authored-by: Lilla Barancsuk <barancsuklilla@gmail.com>
We can build it with -Werror=global-constructors now. This helps
in situation where libSupport is embedded as a shared library,
potential with dlopen/dlclose scenario, and when command-line
parsing or other facilities may not be involved. Avoiding the
implicit construction of these cl::opt can avoid double-registration
issues and other kind of behavior.
Reviewed By: lattner, jpienaar
Differential Revision: https://reviews.llvm.org/D105959
We can build it with -Werror=global-constructors now. This helps
in situation where libSupport is embedded as a shared library,
potential with dlopen/dlclose scenario, and when command-line
parsing or other facilities may not be involved. Avoiding the
implicit construction of these cl::opt can avoid double-registration
issues and other kind of behavior.
Reviewed By: lattner, jpienaar
Differential Revision: https://reviews.llvm.org/D105959
We can build it with -Werror=global-constructors now. This helps
in situation where libSupport is embedded as a shared library,
potential with dlopen/dlclose scenario, and when command-line
parsing or other facilities may not be involved. Avoiding the
implicit construction of these cl::opt can avoid double-registration
issues and other kind of behavior.
Reviewed By: lattner, jpienaar
Differential Revision: https://reviews.llvm.org/D105959
This reduces the size of the dependency graph and makes incremental
development a little more pleasant (less rebuilding).
This introduces a bit of complexity/fragility as some tests verify
clang-tidy behavior. I attempted to isolate these and build/run as much
of the tests as possible in both configs to prevent rot.
Expectation is that (some) developers will use this locally, but
buildbots etc will keep testing clang-tidy.
Fixes https://github.com/clangd/clangd/issues/233
Differential Revision: https://reviews.llvm.org/D105679
When deleting the copy assignment statement because copied variable is not used
only remove trailing comments on the same line.
Differential Revision: https://reviews.llvm.org/D105734
Reviewed-by: ymandel
Structured bindings can currently trigger the check and lead to a wrong
fix. Because the DecompositionDecl itself is not used and the check does not
iterate through its the decl's bindings to verify whether the bindings' holding
vars are used this leads to the whole statement to be deleted.
To support structured bindings properly 3 cases would need to be considered.
1. All holding vars are not used -> The statement can be deleted.
2. All holding vars are used as const or not used -> auto can be converted to const auto&.
3. Neither case is true -> leave unchanged.
In the check we'll have to separate the logic that determines this from the code
that produces the diagnostic and fixes and first determine which of the cases
we're dealing with before creating fixes.
Since this is a bigger refactoring we'll disable structured bindings for now to
prevent incorrect fixes.
Differential Revision: https://reviews.llvm.org/D105727
Reviewed-by: ymandel
C++23 will make these conversions ambiguous - so fix them to make the
codebase forward-compatible with C++23 (& a follow-up change I've made
will make this ambiguous/invalid even in <C++23 so we don't regress
this & it generally improves the code anyway)
This adds a new llvm::thread class with the same interface as std::thread
except there is an extra constructor that allows us to set the new thread's
stack size. On Darwin even the default size is boosted to 8MB to match the main
thread.
It also switches all users of the older C-style `llvm_execute_on_thread` API
family over to `llvm::thread` followed by either a `detach` or `join` call and
removes the old API.
Moved definition of DefaultStackSize into the .cpp file to hopefully
fix the build on some (GCC-6?) machines.
This adds a new llvm::thread class with the same interface as std::thread
except there is an extra constructor that allows us to set the new thread's
stack size. On Darwin even the default size is boosted to 8MB to match the main
thread.
It also switches all users of the older C-style `llvm_execute_on_thread` API
family over to `llvm::thread` followed by either a `detach` or `join` call and
removes the old API.
Compiling clangd with Clang modules and libc++ revealed that
`support/Threading.h` uses `std::atomic` but wasn't including the
correct header.
Differential Revision: https://reviews.llvm.org/D105400
BlockUntilIdle is supposed to return false if it fails.
If an intermediate step fails to clear the queue, we shouldn't
charge ahead and assert on the state of the queue.
For files directly under clangd/, -Iclang-tools-extra/clangd (and the
equivalent for generated files) are not required, as CMake/the compiler puts
these directories on the include path by default.
However this means each subdirectory needs to
include_directories(.. ${CMAKE_CURRENT_BINARY_DIR}/..) etc, and this
proved annoying and error-prone to maintain and debug.
Since include_directories is inherited by subdirectories, we just
configure this explicitly at the top level instead.
This reverts b56e5f8a10 (and follow-up f6db88535c) and instead
restores the state we had before 0c96a92d8666b8: ClangdMain.cpp
includes Features.inc before including Transport.h.
This is a bit ugly, but it matches the former state and making Transport.h
include Features.h means that xpc/ needs to be able to find the generated
Features.inc, wich is also a bit ugly.
Without this patch clangd silently process compiler instance prepare failure and only LSP errors "Invalid AST" could be found in logs.
E.g. the reason of the problem https://github.com/clangd/clangd/issues/734 is impossible to understand without verbose logs or with disabled background index.
This patch adds more information into logs to help understand the reason of such failures.
Logs without this patch:
```
E[...] Could not build a preamble for file test.cpp version 1
```
Logs with this patch:
```
E[...] Could not build a preamble for file test.cpp version 1: CreateTargetInfo() return null
..
E[...] Failed to prepare a compiler instance: unknown target ABI 'lp64'
```
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D104056
That commit removed the include of Features.inc from ClangdLSPServer.h,
but ClangdMain.cpp relied on this include to pull in Features.inc for
the #if at the bottom of Transport.h.
Since the include is needed in Transport.h, just add it to there
directly.
Objective-C lets you use the `self.prop` syntax as sugar for both
`[self prop]` and `[self setProp:]`, but clangd previously did not
provide a semantic token for `prop`.
Now, we provide a semantic token, treating it like a normal property
except it's backed by a `ObjCMethodDecl` instead of a
`ObjCPropertyDecl`.
Differential Revision: https://reviews.llvm.org/D104117
This displays as: `Size: 4 bytes (+4 padding)`
Also stop showing (byte) offset/size for bitfields. They're not
meaningful and using them to calculate padding is dangerous!
Differential Revision: https://reviews.llvm.org/D98377
Some tweaks might edit file types not supported by clang-format. This
patch gives them a way to signal that they do not require formatting.
Differential Revision: https://reviews.llvm.org/D105039
While the original check's purpose is to identify potentially dangerous
functions based on the parameter types (as identifier names do not mean
anything when it comes to the language rules), unfortunately, such a plain
interface check rule can be incredibly noisy. While the previous
"filtering heuristic" is able to find many similar usages, there is an entire
class of parameters that should not be warned about very easily mixed by that
check: parameters that have a name and their name follows a pattern,
e.g. `text1, text2, text3, ...`.`
This patch implements a simple, but powerful rule, that allows us to detect
such cases and ensure that no warnings are emitted for parameter sequences that
follow a pattern, even if their types allow for them to be potentially mixed at a call site.
Given a threshold `k`, warnings about two parameters are filtered from the
result set if the names of the parameters are either prefixes or suffixes of
each other, with at most k letters difference on the non-common end.
(Assuming that the names themselves are at least `k` long.)
- The above `text1, text2` is an example of this. (Live finding from Xerces.)
- `LHS` and `RHS` are also fitting the bill here. (Live finding from... virtually any project.)
- So does `Qmat, Tmat, Rmat`. (Live finding from I think OpenCV.)
Reviewed By: aaron.ballman
Differential Revision: http://reviews.llvm.org/D97297
There are several types of functions and various reasons why some
"swappable parameters" cannot be fixed with changing the parameters' types, etc.
The most common example might be int `min(int a, int b)`... no matter what you
do, the two parameters must remain the same type.
The **filtering heuristic** implemented in this patch deals with trying to find
such functions during the modelling and building of the swappable parameter
range.
If the parameter currently scrutinised matches either of the predicates below,
it will be regarded as **not swappable** even if the type of the parameter
matches.
Reviewed By: aaron.ballman
Differential Revision: http://reviews.llvm.org/D78652
Adds a relaxation option ModelImplicitConversions which will make the check
report for cases where parameters refer to types that are implicitly
convertible to one another.
Example:
struct IntBox { IntBox(int); operator int(); };
void foo(int i, double d, IntBox ib) {}
Implicit conversions are the last to model in the set of things that are
reasons for the possibility of a function being called the wrong way which is
not always immediately apparent when looking at the function (signature or
call).
Reviewed By: aaron.ballman, martong
Differential Revision: http://reviews.llvm.org/D75041
Adds a relaxation option QualifiersMix which will make the check report for
cases where parameters refer to the same type if they only differ in qualifiers.
This makes cases, such as the following, not warned about by default, produce
a warning.
void* memcpy(void* dst, const void* src, unsigned size) {}
However, unless people meticulously const their local variables, unfortunately,
even such a function carry a potential swap:
T* obj = new T; // Not const!!!
void* buf = malloc(sizeof(T));
memcpy(obj, buf, sizeof(T));
// ^~~ ^~~ accidental swap here, even though the interface "specified" a const.
Reviewed By: aaron.ballman
Differential Revision: http://reviews.llvm.org/D96355
The base patch only deals with strict (canonical) type equality, which is
merely a subset of all the dangerous function interfaces that we intend to
find.
In addition, in the base patch, canonical type equivalence is not diagnosed in
a way that is immediately apparent to the user.
This patch extends the check with two features:
* Proper typedef diagnostics and explanations to the user.
* "Reference bind power" matching.
Case 2 is a necessary addition because in every case someone encounters a
function `f(T t, const T& tr)`, any expression that might be passed to either
can be passed to both. Thus, such adjacent parameter sequences should be
matched.
Reviewed By: aaron.ballman
Differential Revision: http://reviews.llvm.org/D95736
Finds function definitions where parameters of convertible types follow
each other directly, making call sites prone to calling the function
with swapped (or badly ordered) arguments.
Such constructs are usually the result of inefficient design and lack of
exploitation of strong type capabilities that are possible in the
language.
This check finds and flags **function definitions** and **not** call
sites!
Reviewed By: aaron.ballman, alexfh
Differential Revision: http://reviews.llvm.org/D69560
They are already provided by Sema, deserializing from preamble if need
be. Moreover category names are meaningless outside interface/implementation
context, hence they were only causing noise.
Differential Revision: https://reviews.llvm.org/D104540
This fixes false positive cases where a reference is initialized outside of a
block statement and then its initializing variable is modified. Another case is
when the looped over container is modified.
Differential Revision: https://reviews.llvm.org/D103021
Reviewed-by: ymandel
Ignored diagnostics were only checked after level adjusters and assumed
it would stay the same for the rest. But it can also be modified by
FeatureModules.
Differential Revision: https://reviews.llvm.org/D103387
Given `int foo, bar;`, TraverseAST reveals this tree:
TranslationUnitDecl
- foo
- bar
Before this patch, with the TraversalScope set to {foo}, TraverseAST yields:
foo
After this patch it yields:
TranslationUnitDecl
- foo
Also, TraverseDecl(TranslationUnitDecl) now respects the traversal scope.
---
The main effect of this today is that clang-tidy checks that match the
translationUnitDecl(), either in order to traverse it or check
parentage, should work.
Differential Revision: https://reviews.llvm.org/D104071
<string> is currently the highest impact header in a clang+llvm build:
https://commondatastorage.googleapis.com/chromium-browser-clang/llvm-include-analysis.html
One of the most common places this is being included is the APInt.h header, which needs it for an old toString() implementation that returns std::string - an inefficient method compared to the SmallString versions that it actually wraps.
This patch replaces these APInt/APSInt methods with a pair of llvm::toString() helpers inside StringExtras.h, adjusts users accordingly and removes the <string> from APInt.h - I was hoping that more of these users could be converted to use the SmallString methods, but it appears that most end up creating a std::string anyhow. I avoided trying to use the raw_ostream << operators as well as I didn't want to lose having the integer radix explicit in the code.
Differential Revision: https://reviews.llvm.org/D103888
mixed integer and floating point types with WarnOnEquivalentBitWidth=0.
Also standardize control flow of handleX conversion functions to make it easier to be consistent.
Patch by Stephen Concannon!
Differential Revision: https://reviews.llvm.org/D103894
There is a followup fix for a unit test introduced at D102906. The test file was placed into a temp folder and test assumed that it would be visible without the full path specification.
This behaviour can be changed in future and it would be good to specify full path to the file at the test.
Test Plan:
```
ninja check-clang-tools
```
Reviewed By: DmitryPolukhin
Differential Revision: https://reviews.llvm.org/D104021
Saleem Abdulrasool