Recent changes to add _BitInt support have caused our internal random
testing to fail. This change just avoids a readability magic numbers
check for now if a _BitInt. The crash seen (edited for clarity) is shown
below.
<src-root>/llvm/include/llvm/ADT/APInt.h:1488:
uint64_t llvm::APInt::getZExtValue() const: Assertion `getActiveBits()
<= 64 && "Too many bits for uint64_t"' failed.
...
#9 <address> llvm::APInt::getZExtValue() const
<src-root>/llvm/include/llvm/ADT/APInt.h:1488:5
clang::IntegerLiteral const*) const
<src-root>/clang-tools-extra/clang-tidy/readability/MagicNumbersCheck.cpp:198:47
<clang::IntegerLiteral>(clang::ast_matchers::MatchFinder::MatchResult
const&, char const*)
<src-root>/clang-tools-extra/clang-tidy/readability/MagicNumbersCheck.h:67:5
clang::ast_matchers::MatchFinder::MatchResult const&)
<src-root>/clang-tools-extra/clang-tidy/readability/MagicNumbersCheck.cpp:152:35
...
Reviewed By: donat.nagy
The template is agnostic as to the type used by the list, as long as it
is
compatible with `llvm::move` and `std::back_inserter`. In practice,
we've
encountered analyses which use different types (`llvm::SmallVector` vs
`std::vector`), so it seems preferable to leave this open to the caller.
Some clang multilib configurations (such as the one currently used in
the [beta ARM LLVM
toolchain](https://github.com/ARM-software/LLVM-embedded-toolchain-for-Arm))
wind up only reporting the C++ include paths properly if they get passed
the correct target. This patch ensures the `--target` (or `-target`)
arguments are correctly sent to the queried driver.
Support for extracting lambda expressions, e.g. extracting a lambda from a callexpr (e.g. algorithms/ranges) to a named variable.
Reviewed By: nridge
Differential Revision: https://reviews.llvm.org/D141757
Due to guaranteed copy elision, not only do some nodes get removed from the AST,
but also some existing nodes change the source locations they correspond to.
Hence, the check works slightly differently in pre-C++17 and C++17-and-later modes
in terms of what gets highlighted.
Reviewed By: PiotrZSL
Differential Revision: https://reviews.llvm.org/D158371
New option added and configured in a way, so types
related to std::strong_ordering would be ignored.
Fixes: #63478
Reviewed By: ccotter
Differential Revision: https://reviews.llvm.org/D158928
After 98e6deb6 the 'HeadersForSymbolTest.IWYUTransitiveExportWithPrivate' test in 'ClangIncludeCleanerTest' started failing. This is most likely because `FileEntryRef::getName()` now starts with ".\" on Windows, whereas `FileEntry::getName()` did not. This commit fixes assumption of forward slash separators.
There is a long-standing FIXME in `HeaderSearch.cpp` to use the path separator preferred by the platform instead of forward slash. There was an attempt to fix that (1cf6c28a) which got reverted (cf385dc8). I couldn't find an explanation, but my guess is that some tests assuming forward slash started failing.
This commit fixes tests with that assumption.
This is intended to be NFC, but there are two exceptions to that:
* Some diagnostic messages might now contain backslash instead of forward slash.
* Arguments to the "-remap-file" option that use forward slash might stop kicking in. Separators between potential includer path and header name need to be replaced by backslash in that case.
Fixed#65055
For normal type, typedef is from typedef to the end of original type,
but for function pointer it is from typedef to the end.
So it needs to consider alias name length for normal type.
Putting preferred header signal above completeness implied we would
uprank forward declarations above complete ones in certain cases.
This can be desired in cases where:
- Complete definition is private. But this case is already governed by
publicness signal.
- The library indeed intends to provide a forward declaring interface, like
iosfwd vs ostream.
In all other cases, upranking is undesired as it means we've picked up prefered
headerness signal by mistake from an unrelated declaration to the library.
This change regresses the behavior for libraries that intentionally provide a
forward declaring interface. But that wasn't something we intended to support
explicitly, it was working incidentally when the forward declaring header had a
similar name to the symbol. Moreover, include-cleaner deliberately discourages
forward-declarations, so not working in this case is also more aligned with rest
of the components.
Differential Revision: https://reviews.llvm.org/D159441
We started seeing a lot of timeouts that align with the change in lit to
execute gtests in shards. The logic there assumes tests are
single-threaded, which is the case for most of the LLVM, hence they
pick #shards ~ #cores (by slightly overshooting).
There are enough unittests in clangd that rely on multi-threading, they
can create arbitrarily many threads but we limit amount of meaningful
work to ~4 thread per process.
This change ensures that we're accounting for that paralelism when
executing clangd tests and not overloading test executors.
In theory the change overestimates the requirements, not all tests are
multi-threaded, but it doesn't seem to be resulting in any regressions
on my local runs.
Fixes https://github.com/llvm/llvm-project/issues/64964.
Fixes https://github.com/clangd/clangd/issues/1712.
This is a follow-up patch for D148088. The dynamic symbol index (`FileIndex::updatePreamble`) may run in a separate thread, and the `DiagnosticConsumer` that is set up in `buildPreamble` might go out of scope before it is used. This could result in a SIGSEGV when attempting to call any method of the `DiagnosticConsumer` class.
The function `buildPreamble` sets up the `DiagnosticConsumer` as follows:
```
... buildPreamble(...) {
...
StoreDiags PreambleDiagnostics;
...
llvm::IntrusiveRefCntPtr<DiagnosticsEngine> PreambleDiagsEngine =
CompilerInstance::createDiagnostics(&CI.getDiagnosticOpts(),
&PreambleDiagnostics,
/*ShouldOwnClient=*/false);
...
// The call might use the diagnostic consumer in a separate thread
PreambleCallback(...)
...
}
```
`PreambleDiagnostics` might be out of scope for `buildPreamble` function when we call it inside `PreambleCallback` in a separate thread.
The Fix
The fix involves replacing the client (DiagnosticConsumer) with an `IgnoringDiagConsumer` instance, which will print messages to the clangd log.
Alternatively, we can replace `PreambleDiagnostics` with an object that is owned by `DiagnosticsEngine`.
Note
There is no corresponding LIT/GTest for this issue, since there is a specific race condition that is difficult to reproduce within a test framework.
Test Plan:
```
ninja check-clangd
```
Reviewed By: kadircet, sammccall
Differential Revision: https://reviews.llvm.org/D159363
Now we can store it in DynTypedNode, we can target these nodes
(SelectionTree) and resolve them (FindTarget).
This makes Hover, go-to-def etc work in all(?) cases.
Also support it in DumpAST.
Differential Revision: https://reviews.llvm.org/D159299
…-delete
So the purpose of the check is more clear. Update examples code to show
compliant code.
Fixes#65221
---------
Co-authored-by: Carlos Gálvez <carlos.galvez@zenseact.com>
Special members marked as used, or with out-of-line
definition should not raise an warning now.
Fixes: #33759
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D158486
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
`clang::runWithSufficientStackSpace` requires the address of the
initial stack bottom to prevent potential stack overflows.
In addition, add a fallback to ASTFrontendAction in case any client
forgets to call it when not through CompilerInstance::ExecuteAction,
which is rare.
Fixes https://github.com/clangd/clangd/issues/1745.
Reviewed By: sammccall
Differential Revision: https://reviews.llvm.org/D158967
Modify script to fail when some run clang-tidy
command fails. Based on run_clang-tidy.
Fixes: #65000
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D158929
When using agressive inlining -Xclang -mllvm -Xclang -inline-threshold=500,
this file takes 10-18 min to compile. This is caused by in-direct recursion.
Looks like transforming code to use templates and lambdas instead of
std::function and member function pointer reduces this time to 0.5s.
Fixes: #59658
Directly traverse `ConceptReference`s in FindTarget.cpp.
There is no need for the extra logic for `AutoTypeLoc`s in SemanticHightlighting.cpp as the concept information is stored in a `ConceptReference` which is now traversed.
Differential Revision: https://reviews.llvm.org/D159268
stdarg.h and stddef.h have to be textual headers in their upcoming modules to support their `__needs_xxx` macros. That means that they won't get precompiled into their modules' pcm, and instead their declarations will go into every other pcm that uses them. For now that's ok since the type merger can handle the declarations in these headers, but it's suboptimal at best. Make separate headers for all of the pieces so that they can be properly modularized.
Reviewed By: aaron.ballman, ChuanqiXu
Differential Revision: https://reviews.llvm.org/D158709
Old links pointed out to old domain, and then redirected to correct
one, but to wrong pages. Changed links from old to new domain and page.
Fixes: #65064
