Summary:
This is a tricky case (we baked the assumption that symbols come from
the preamble xor mainfile pretty deeply) and the fix is a bit of a hack:
We look at the code to guess the macro names, and deserialize them from
the preamble "by hand".
Reviewers: ilya-biryukov
Subscribers: ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60937
........
Fix buildbots http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/47684/
llvm-svn: 359796
Summary:
This is a tricky case (we baked the assumption that symbols come from
the preamble xor mainfile pretty deeply) and the fix is a bit of a hack:
We look at the code to guess the macro names, and deserialize them from
the preamble "by hand".
Reviewers: ilya-biryukov
Subscribers: ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60937
llvm-svn: 359778
Summary:
Previously we were just jumping from the symbol index to the symbol page, and
grabbing all the headers mentioned there. But the page often lists multiple
symbols, and so we got false positives and thus ambiguities (which were dropped).
Now we look at which declarations are for the symbol we want, and prefer headers
listed above that symbol. If there are none, we fall back to the old behavior.
Reviewers: kadircet
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61316
llvm-svn: 359771
D61187 didn't delete config.clangd_xpc_support from test/
CLANGD_BUILD_XPC is defined in clangd/CMakeLists.txt and not available in test/lit.site.cfg.py.in
llvm-svn: 359428
Summary:
Motivation:
- this layout is a pain to work with
- without a common root, it's painful to express things like "disable clangd" (D61122)
- CMake/lit configs are a maintenance hazard, and the more the one-off hacks
for various tools are entangled, the more we see apathy and non-ownership.
This attempts to use the bare-minimum configuration needed (while still
supporting the difficult cases: windows, standalone clang build, dynamic libs).
In particular the lit.cfg.py and lit.site.cfg.py.in are merged into lit.cfg.in.
The logic in these files is now minimal.
(Much of clang-tools-extra's lit configs can probably be cleaned up by reusing
lit.llvm.llvm_config.use_clang(), and every llvm project does its own version of
LDPATH mangling. I haven't attempted to fix any of those).
Docs are still in clang-tools-extra/docs, I don't have any plans to touch those.
Reviewers: gribozavr
Subscribers: mgorny, javed.absar, MaskRay, jkorous, arphaman, kadircet, jfb, cfe-commits, ilya-biryukov, thakis
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61187
llvm-svn: 359424
Summary: We scrape the enclosing scopes from the source file, and use them in the query.
Reviewers: kadircet
Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61077
llvm-svn: 359284
Summary:
llvm::Regex is really slow, and regex evaluation during preamble indexing was
showing up as 25% on a profile of clangd in a codebase with large preambles.
Reviewers: ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61120
llvm-svn: 359214
Summary:
Annotations allow writing nice-looking unit test code when one needs
access to locations from the source code, e.g. running code completion
at particular offsets in a file. See comments in Annotations.cpp for
more details on the API.
Also got rid of a duplicate annotations parsing code in clang's code
complete tests.
Reviewers: gribozavr, sammccall
Reviewed By: gribozavr
Subscribers: mgorny, hiraditya, ioeric, MaskRay, jkorous, arphaman, kadircet, jdoerfert, cfe-commits, llvm-commits
Tags: #clang, #llvm
Differential Revision: https://reviews.llvm.org/D59814
llvm-svn: 359179
Summary:
Looks at conditionals and finds cases of ``cast<>``, which will
assert rather than return a null pointer, and ``dyn_cast<>`` where
the return value is not captured. Additionally, finds cases that
match the pattern ``var.foo() && isa<X>(var.foo())``, where the
method is called twice and could be expensive.
.. code-block:: c++
// Finds cases like these:
if (auto x = cast<X>(y)) <...>
if (cast<X>(y)) <...>
// But not cases like these:
if (auto f = cast<Z>(y)->foo()) <...>
if (cast<Z>(y)->foo()) <...>
Reviewers: alexfh, rjmccall, hokein, aaron.ballman, JonasToth
Reviewed By: aaron.ballman
Subscribers: xbolva00, Eugene.Zelenko, mgorny, xazax.hun, cfe-commits
Tags: #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D59802
llvm-svn: 359142
Summary:
Include insertion in clangd was inserting absolute paths when the
include directory was an absolute path with a double dot. This patch makes sure
double dots are handled both with absolute and relative paths.
Reviewers: sammccall
Subscribers: ilya-biryukov, ioeric, jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60873
llvm-svn: 359078
It now comes with a follow-up fix for the clients of this API
in clangd and clang-tidy.
Differential Revision: https://reviews.llvm.org/D59977
llvm-svn: 359035
Patch by Nathan Ridge!
Dependent bases are handled heuristically, by replacing them with the
class template that they are a specialization of, where possible. Care
is taken to avoid infinite recursion.
Differential Revision: https://reviews.llvm.org/D59756
llvm-svn: 358866
Summary:
It's never set to true. Its only effect would be to set stdout to binary mode.
Hopefully we have better ways of doing this by now :-)
Reviewers: hokein
Subscribers: jkorous, arphaman, kadircet, llvm-commits
Tags: #llvm
Differential Revision: https://reviews.llvm.org/D60871
llvm-svn: 358696
Summary: We already have the structure internally, we just need to expose it.
Reviewers: ilya-biryukov
Subscribers: ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60267
llvm-svn: 358675
Summary:
Also add a test to verify clang-tidy only apply the first alternative
fix.
Reviewers: alexfh
Subscribers: xazax.hun, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60857
llvm-svn: 358666
Summary:
Currently we emit an unfriendly "clang diagnostic" message when rename fails. This
patch makes clangd to emit a detailed diagnostic message.
Reviewers: sammccall
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60821
llvm-svn: 358658
Before the patch calling clang-tidy with -header-filter=.* -system-headers would
result in a few hundred useless warnings:
warning: macro '_GNU_SOURCE' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '_LP64' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_ACQUIRE' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_ACQ_REL' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_CONSUME' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_RELAXED' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_RELEASE' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__ATOMIC_SEQ_CST' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
warning: macro '__BIGGEST_ALIGNMENT__' used to declare a constant; consider using a 'constexpr' constant [cppcoreguidelines-macro-usage]
... and so on
llvm-svn: 358621
Summary:
This check aims to address a relatively common benign error where
Objective-C subclass initializers call -self on their superclass instead
of invoking a superclass initializer, typically -init. The error is
typically benign because libobjc recognizes that improper initializer
chaining is common¹.
One theory for the frequency of this error might be that -init and -self
have the same return type which could potentially cause inappropriate
autocompletion to -self instead of -init. The equal selector lengths and
triviality of common initializer code probably contribute to errors like
this slipping through code review undetected.
This check aims to flag errors of this form in the interests of
correctness and reduce incidence of initialization failing to chain to
-[NSObject init].
[1] "In practice, it will be hard to rely on this function.
Many classes do not properly chain -init calls."
From _objc_rootInit in https://opensource.apple.com/source/objc4/objc4-750.1/runtime/NSObject.mm.auto.html.
Test Notes:
Verified via `make check-clang-tools`.
Subscribers: mgorny, xazax.hun, jdoerfert, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D59806
llvm-svn: 358620
Summary:
- for warnings, use the flag the warning is controlled by (-Wfoo)
- for errors, keep using the internal name (there's nothing better) but
drop the err_ prefix
This comes at the cost of uniformity, it's no longer totally obvious
exactly what the code field contains. But the -Wname flags are so much
more useful to end-users than the internal warn_foo that this seems worth it.
Reviewers: kadircet
Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60822
llvm-svn: 358611
Summary:
Typically used with umbrella headers, e.g. GTK:
#if !defined (__GTK_H_INSIDE__) && !defined (GTK_COMPILATION)
#error "Only <gtk/gtk.h> can be included directly."
#endif
Heuristic is fairly conservative, a quick code search over github showed
a fair number of hits and few/no false positives. (Not all were umbrella
headers, but I'd be happy avoiding include insertion for all of them).
We may want to relax the heuristic later to catch more cases.
Reviewers: ioeric
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60815
llvm-svn: 358605
Before this patch readability-misleading-indentation could issue diagnostics
with an invalid location, which would lead to an assertion failure in
ClangTidyContext::diag()
llvm-svn: 358589
Summary:
Motivation/Context: in the code review system integrating with clang-tidy,
clang-tidy doesn't provide a human-readable description of the fix. Usually
developers have to preview a code diff (before vs after apply the fix) to
understand what the fix does before applying a fix.
This patch proposes that each clang-tidy check provides a short and
actional fix description that can be shown in the UI, so that users can know
what the fix does without previewing diff.
This patch extends clang-tidy framework to support fix descriptions (will add implementations for
existing checks in the future). Fix descriptions and fixes are emitted via diagnostic::Note (rather than
attaching the main warning diagnostic).
Before this patch:
```
void MyCheck::check(...) {
...
diag(loc, "my check warning") << FixtItHint::CreateReplacement(...);
}
```
After:
```
void MyCheck::check(...) {
...
diag(loc, "my check warning"); // Emit a check warning
diag(loc, "fix description", DiagnosticIDs::Note) << FixtItHint::CreateReplacement(...); // Emit a diagnostic note and a fix
}
```
Reviewers: sammccall, alexfh
Reviewed By: alexfh
Subscribers: MyDeveloperDay, Eugene.Zelenko, aaron.ballman, JonasToth, xazax.hun, jdoerfert, cfe-commits
Tags: #clang-tools-extra, #clang
Differential Revision: https://reviews.llvm.org/D59932
llvm-svn: 358576
Summary:
We do have some reports of include insertion behaving badly in some
codebases. Requiring header guards both makes sense in principle, and is
likely to disable this "nice-to-have" feature in codebases where headers don't
follow the expected pattern.
With this we can drop some other heuristics, such as looking at file
extensions to detect known non-headers - implementation files have no guards.
One wrinkle here is #import - objc headers may not have guards because
they're intended to be used via #import. If the header is the main file
or is #included, we won't collect locations - merge should take care of
this if we see the file #imported somewhere. Seems likely to be OK.
Headers which have a canonicalization (stdlib, IWYU) are exempt from this check.
*.inc files continue to be handled by looking up to the including file.
This patch also adds *.def here - tablegen wants this pattern too.
In terms of code structure, the division between SymbolCollector and
CanonicalIncludes has shifted: SymbolCollector is responsible for more.
This is because SymbolCollector has all the SourceManager/HeaderSearch access
needed for checking for guards, and we interleave these checks with the *.def
checks in a loop (potentially).
We could hand all the info into CanonicalIncludes and put the logic there
if that's preferable.
Reviewers: ioeric
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60316
llvm-svn: 358571
Summary:
Previously, we would use include spelling of the declaring header to check
whether the inserted header is the same as the main file. This doesn't help because
we only have file path of the main file.
Reviewers: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60687
llvm-svn: 358496
Summary:
Some implicit/built-in decls lack the source location
information. Fallback to OrigD that we've seen in the source code
instead of the canonical one in those cases.
Reviewers: sammccall
Subscribers: cfe-commits, arphaman, jkorous, MaskRay, ioeric, ilya-biryukov
Tags: #clang
Differential Revision: https://reviews.llvm.org/D60689
llvm-svn: 358413
Florian Gross