Summary:
This has a shape to similar logarithm function but grows much slower for
large #usages.
Metrics: https://reviews.llvm.org/P8096
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, cfe-commits, sammccall
Differential Revision: https://reviews.llvm.org/D49780
llvm-svn: 337907
This patch introduces the core building block of the next-generation
Clangd symbol index - Dex. Search tokens are the keys in the inverted
index and represent a characteristic of a specific symbol: examples of
search token types (Token Namespaces) are
* Trigrams - these are essential for unqualified symbol name fuzzy
search * Scopes for filtering the symbols by the namespace * Paths, e.g.
these can be used to uprank symbols defined close to the edited file
This patch outlines the generic for such token namespaces, but only
implements trigram generation.
The intuition behind trigram generation algorithm is that each extracted
trigram is a valid sequence for Fuzzy Matcher jumps, proposed
implementation utilize existing FuzzyMatcher API for segmentation and
trigram extraction.
However, trigrams generation algorithm for the query string is different
from the previous one: it simply yields sequences of 3 consecutive
lowercased valid characters (letters, digits).
Dex RFC in the mailing list:
http://lists.llvm.org/pipermail/clangd-dev/2018-July/000022.html
The trigram generation techniques are described in detail in the
proposal:
https://docs.google.com/document/d/1C-A6PGT6TynyaX4PXyExNMiGmJ2jL1UwV91Kyx11gOI/edit#heading=h.903u1zon9nkj
Reviewers: sammccall, ioeric, ilya-biryukovA
Subscribers: cfe-commits, klimek, mgorny, MaskRay, jkorous, arphaman
Differential Revision: https://reviews.llvm.org/D49591
llvm-svn: 337901
Summary:
The cppcoreguidelines-pro-bounds-pointer-arithmetic warns on all occassion where
pointer arithmetic is used, but does not check values where the pointer types
is deduced via `auto`. This patch adjusts this behaviour and solved
PR36489.
I accidentally commited a wrong patch, this Differential is meant to have a
correct revision description and code attached to it.
Because the patch was accepted by aaron.ballman already, i will just commit
it.
See https://reviews.llvm.org/D48717 for the old differntial (contains wrong
code from the mixup)
Subscribers: nemanjai, xazax.hun, kbarton, cfe-commits
Differential Revision: https://reviews.llvm.org/D49682
llvm-svn: 337716
Summary:
The cppcoreguidelines-pro-bounds-pointer-arithmetic warns on all occassion where
pointer arithmetic is used, but does not check values where the pointer types
is deduced via ``auto``. This patch adjusts this behaviour and solved
PR36489.
Reviewers: alexfh, aaron.ballman, hokein, ilya-biryukov
Reviewed By: alexfh, aaron.ballman
Subscribers: nemanjai, xazax.hun, kbarton, cfe-commits
Differential Revision: https://reviews.llvm.org/D48717
llvm-svn: 337710
Summary:
This patch removes a private matcher in fuchsia/TrailingReturnType check because
the matcher is now in ASTMatchers
Reviewers: aaron.ballman, alexfh, hokein
Reviewed By: aaron.ballman
Subscribers: xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D49618
llvm-svn: 337707
Summary:
The following are metrics for explicit member access completions. There is no
noticeable impact on other completion types.
Before:
EXPLICIT_MEMBER_ACCESS
Total measurements: 24382
All measurements: MRR: 62.27 Top10: 80.21% Top-100: 94.48%
Full identifiers: MRR: 98.81 Top10: 99.89% Top-100: 99.95%
0-5 filter len:
MRR: 13.25 46.31 62.47 67.77 70.40 81.91
Top-10: 29% 74% 84% 91% 91% 97%
Top-100: 67% 99% 99% 99% 99% 100%
After:
EXPLICIT_MEMBER_ACCESS
Total measurements: 24382
All measurements: MRR: 63.18 Top10: 80.58% Top-100: 95.07%
Full identifiers: MRR: 98.79 Top10: 99.89% Top-100: 99.95%
0-5 filter len:
MRR: 13.84 48.39 63.55 68.83 71.28 82.64
Top-10: 30% 75% 84% 91% 91% 97%
Top-100: 70% 99% 99% 99% 99% 100%
* Top-N: wanted result is found in the first N completion results.
* MRR: Mean reciprocal rank.
Remark: the change seems to have minor positive impact. Although the improvement
is relatively small, down-ranking non-instance members in instance member access
should reduce noise in the completion results.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D49543
llvm-svn: 337681
Upstreaming the script I use to generate clang-doc tests (and updating
the existing tests to use it)
Differential Revision: https://reviews.llvm.org/D49268
llvm-svn: 337632
Submitted on behalf of Annie Cherkaev (@anniecherk)
Added a flag which, when enabled, documents only those methods and
fields which have a Public attribute.
Differential Revision: https://reviews.llvm.org/D48395
llvm-svn: 337602
Summary: This is intended to be used for indexing, e.g. in D49417
Reviewers: ioeric, omtcyfz
Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D49540
llvm-svn: 337527
Summary:
Hello, i would like to suggest a fix for one of the checks in clang-tidy.
The bug was reported in https://bugs.llvm.org/show_bug.cgi?id=38039 where you can find more information.
```
struct UOB{
UOB(const UOB &Other):j{Other.j}{}
int j;
};
```
In this case the check modernize-use-equals-default does not detect copy constructors that can be defaulted; that should be:
```
struct UOB{
UOB(const UOB &Other) = default;
int j;
};
```
Reviewers: aaron.ballman, hokein, alexfh
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D49356
llvm-svn: 337286
Finds functions which may throw an exception directly or indirectly, but they
should not: Destructors, move constructors, move assignment operators, the
main() function, swap() functions, functions marked with throw() or noexcept
and functions given as option to the checker.
Differential Revision: https://reviews.llvm.org/D33537
llvm-svn: 336997
Summary:
The goal is to reduce false positives when the difference is intentional, like:
foo(StringRef name);
foo(StringRef name_ref) {
string name = cleanup(name_ref);
...
}
Or semantically unimportant, like:
foo(StringRef full_name);
foo(StringRef name) { ... }
There are other matching names we won't recognise (e.g. syns vs synonyms) but
this catches many that we see in practice, and gives people a systematic
workaround.
The old behavior is available as a 'Strict' option.
Subscribers: xazax.hun, cfe-commits
Differential Revision: https://reviews.llvm.org/D49285
llvm-svn: 336992
Having `using qualified::name;` for some symbol is an important signal
for clangd code completion as the user is more likely to use such
symbol. This patch helps to uprank the relevant symbols by saving
UsingShadowDecl in the new field of CodeCompletionResult and checking
whether the corresponding UsingShadowDecl is located in the main file
later in ClangD code completion routine. While the relative importance
of such signal is a subject to change in the future, this patch simply
bumps DeclProximity score to the value of 1.0 which should be enough for
now.
The patch was tested using
`$ ninja check-clang check-clang-tools`
No unexpected failures were noticed after running the relevant testsets.
Reviewers: sammccall, ioeric
Subscribers: MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49012
llvm-svn: 336810
Summary:
Sema code complete in the recovery mode is generally useless. For many
cases, sema first completes in recovery context and then recovers to more useful
context, in which it's favorable to ignore results from recovery (as results are
often bad e.g. all builtin symbols and top-level symbols). There is also case
where only sema would fail to recover e.g. completions in excluded #if block.
Sema would try to give results, but the results are often useless (see the updated
excluded #if block test).
Reviewers: sammccall, ilya-biryukov
Subscribers: MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49175
llvm-svn: 336801
Summary:
log() is split into four functions:
- elog()/log()/vlog() have different severity levels, allowing filtering
- dlog() is a lazy macro which uses LLVM_DEBUG - it logs to the logger, but
conditionally based on -debug-only flag and is omitted in release builds
All logging functions use formatv-style format strings now, e.g:
log("Could not resolve URI {0}: {1}", URI, Result.takeError());
Existing log sites have been split between elog/log/vlog by best guess.
This includes a workaround for passing Error to formatv that can be
simplified when D49170 or similar lands.
Subscribers: ilya-biryukov, javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49008
llvm-svn: 336785
Summary:
This gives better coverage to the check as ExprMutationAnalyzer is more
accurate comparing to isOnlyUsedAsConst.
Majority of wins come from const usage of member field, e.g.:
for (auto widget : container) { // copy of loop variable
if (widget.type == BUTTON) { // const usage only recognized by ExprMutationAnalyzer
// ...
}
}
Reviewers: george.karpenkov
Subscribers: a.sidorin, cfe-commits
Differential Revision: https://reviews.llvm.org/D48854
llvm-svn: 336737
Summary: This is not enabled in the global-symbol-builder or dynamic index yet.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: ilya-biryukov, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D49028
llvm-svn: 336553
Summary:
The library has graduated from clangd to llvm/Support.
This is a mechanical change to move to the new API and remove the old one.
Main API changes:
- namespace clang::clangd::json --> llvm::json
- json::Expr --> json::Value
- Expr::asString() etc --> Value::getAsString() etc
- unsigned longs need a cast (due to r336541 adding lossless integer support)
Reviewers: ilya-biryukov
Subscribers: mgorny, ioeric, MaskRay, jkorous, omtcyfz, cfe-commits
Differential Revision: https://reviews.llvm.org/D49077
llvm-svn: 336549
Summary:
To avoid wasting time deserializing them on code completion and
further reparses.
We do not use the comments anyway, because we cannot rely on the file
contents staying the same for reparses that reuse the prebuilt
preamble PCH.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D48943
llvm-svn: 336540
Summary:
To avoid doing extra work of processing headers in the preamble
mutilple times in parallel.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: javed.absar, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D48940
llvm-svn: 336538
Summary:
An AST-based approach is used to retrieve the document symbols rather than an
in-memory index query. The index is not an ideal fit to achieve this because of
the file-centric query being done here whereas the index is suited for
project-wide queries. Document symbols also includes more symbols and need to
keep the order as seen in the file.
Signed-off-by: Marc-Andre Laperle <marc-andre.laperle@ericsson.com>
Subscribers: tomgr, ilya-biryukov, ioeric, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D47846
llvm-svn: 336386
Summary:
Following D48903 ([VirtualFileSystem] InMemoryFileSystem::status: Return
a Status with the requested name), the paths output by clang-move in the
FileToReplacements map may contain leading "./". For example, where we
would get "foo.h", we'll now get "./foo.h". This breaks the tests,
because we are doing exact string lookups in the FileToFileID and
Results maps (they contain "foo.h", but we search for "./foo.h").
To mitigate this, try to normalize a little bit the paths output by
clang-move to remove that leading "./".
This patch should be safe to merge before D48903, remove_dots will just
be a no-op.
Reviewers: ilya-biryukov, hokein
Reviewed By: hokein
Subscribers: ioeric, cfe-commits
Differential Revision: https://reviews.llvm.org/D48951
llvm-svn: 336358
This patch is a preparation for another one containing meaningful
changes. This patch simply removes trailing whitespaces in few files
affected by the upcoming patch and reformats
llvm-svn: 336330
The bad behavior seems to have been fixed by r336242 after all.
I thought it was persisting, but that was a different bug fixed by D48940
llvm-svn: 336320
Summary: Surface it in the completion items C++ API, and when a flag is set.
Reviewers: ioeric
Subscribers: ilya-biryukov, MaskRay, jkorous, cfe-commits
Differential Revision: https://reviews.llvm.org/D48938
llvm-svn: 336309
These checks flag use of random number generators with poor seeds that would possibly lead to degraded random number generation.
Patch by Borsik Gábor
llvm-svn: 336301
Eric Liu