Summary:
We put only part of the signature starting with a function name into "typed text"
chunks now, previously the whole signature was "typed text".
This leads to meaningful fuzzy match scores, giving better signals to
compare with other completion items.
Ideally, we would not display the result type to the user, but that requires adding
a new kind of completion chunk.
Reviewers: kadircet
Reviewed By: kadircet
Subscribers: jkorous, arphaman, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D62298
llvm-svn: 361623
Summary:
Where semicolon is required in any case. Here's a list of completions
that now have a semicolon:
- namespace <name> = <target>;
- using namespace <name>;
- using <qualifier>::<name>;
- continue;
- break;
- goto <label>;
- return;
- return <expression>;
Reviewers: gribozavr
Reviewed By: gribozavr
Subscribers: cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D61589
llvm-svn: 360042
Frameworks filesystem representations:
UIKit.framework/Headers/%header%
Framework import format:
#import <UIKit/%header%>
Thus the completion code must map the input format of <UIKit/> to
the path of UIKit.framework/Headers as well as strip the
".framework" suffix when auto-completing the framework name.
llvm-svn: 355008
When Clang/LLVM is built with the CLANG_DEFAULT_STD_CXX CMake macro that sets
the default standard to something other than C++14, there are a number of lit
tests that fail as they rely on the C++14 default.
This patch just adds the language standard option explicitly to such test cases.
Differential revision: https://reviews.llvm.org/D57581
llvm-svn: 353163
Rather than sprinkle calls to DiagnoseUnusedExprResult() around in places where we want diagnostics, we now diagnose unused expression statements and full expressions in a more generic way when acting on the final expression statement. This results in more appropriate diagnostics for [[nodiscard]] where we were previously lacking them, such as when the body of a for loop is not a compound statement.
This patch fixes PR39837.
llvm-svn: 350404
Summary:
The clang used to pick up the qualifiers of the lamba's call operator
(which is always const) and fail to show non-const methods of 'this' in
completion results.
Reviewers: kadircet
Reviewed By: kadircet
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D55885
llvm-svn: 349655
Summary:
...that fires when running completion inside an argument of
UnresolvedMemberExpr (see the added test).
The assertion that fires is from Sema::TryObjectArgumentInitialization:
assert(FromClassification.isLValue());
This happens because Sema::AddFunctionCandidates does not account for
object types which are pointers. It ends up classifying them incorrectly.
All usages of the function outside code completion are used to run
overload resolution for operators. In those cases the object type being
passed is always a non-pointer type, so it's not surprising the function
did not expect a pointer in the object argument.
However, code completion reuses the same function and calls it with the
object argument coming from UnresolvedMemberExpr, which can be a pointer
if the member expr is an arrow ('->') access.
Extending AddFunctionCandidates to allow pointer object types does not
seem too crazy since all the functions down the call chain can properly
handle pointer object types if we properly classify the object argument
as an l-value, i.e. the classification of the implicitly dereferenced
pointer.
Reviewers: kadircet
Reviewed By: kadircet
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D55331
llvm-svn: 348590
Summary:
Similar to auto-completion for ObjC methods, inherited properties
should be penalized / direct class and category properties should
be prioritized.
Note that currently, the penalty for using a result from a base class
(CCD_InBaseClass) is equal to the penalty for using a method as a
property (CCD_MethodAsProperty).
Reviewers: jkorous, sammccall, akyrtzi, arphaman, benlangmuir
Reviewed By: sammccall, akyrtzi
Subscribers: arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D53900
llvm-svn: 347352
Summary:
Removes references to initialized variable from the following completions:
int x = ^;
Handles only the trivial cases where the variable name is completed
immediately at the start of initializer or assignment, more complicated
cases aren't covered, e.g. these completions still contain 'x':
// More complicated expressions.
int x = foo(^);
int x = 10 + ^;
// Other kinds of initialization.
int x{^};
int x(^);
// Constructor initializers.
struct Foo {
Foo() : x(^) {}
int x;
};
We should address those in the future, but they are outside of the scope of
this initial change.
Reviewers: sammccall
Reviewed By: sammccall
Subscribers: arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D54156
llvm-svn: 346301
Summary:
Instead of providing generic "args" for member and base class
initializers, tries to fetch relevant constructors and show their signatures.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: ZaMaZaN4iK, eraman, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D53654
llvm-svn: 345844
Summary:
No new tests as the existing tests for result priority should give us
coverage. Also as the new flag is trivial enough, I'm reluctant to plumb the
flag to c-index-test output.
Reviewers: ilya-biryukov
Reviewed By: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53635
llvm-svn: 345135
Summary:
In a decl like `int AA(BB cc)` where BB isn't defined, we end up trying to
parse `BB cc` as an expression (vexing parse) and end up triggering the
parser's "recovery-in-function" completion with no actual function
scope.
This patch avoids the assumption that such a scope exists in this context.
Reviewers: kadircet
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D53070
llvm-svn: 344133
Summary:
In clangd we had a new type of completion suggestions for cpp
class/struct/unions that will show override signatures for virtual methods in
base classes. This patch implements it in sema because it is hard to deduce more
info about completion token outside of Sema and handle itchy cases.
See the patch D50898 for more info on the functionality.
In addition to above patch this one also converts the suggestion into a
CK_Pattern with whole insertion text as the name of the suggestion and factors
out CodeCompletionString generation for declerations so that it can be re-used
by others.
Reviewers: ioeric, ilya-biryukov
Reviewed By: ioeric
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52225
llvm-svn: 343568
Current completion fix-its approach does not provide OtherOpBase for C code.
But we can easily proceed in this case taking the original Base type.
Differential Revision: https://reviews.llvm.org/D52261
llvm-svn: 342721
Summary:
The dir component ("somedir" in #include <somedir/fo...>) is considered fixed.
We append "foo" to each directory on the include path, and then list its files.
Completions are of the forms:
#include <somedir/fo^
foo.h>
fox/
The filter is set to the filename part ("fo"), so fuzzy matching can be
applied to the filename only.
No fancy scoring/priorities are set, and no information is added to
CodeCompleteResult to make smart scoring possible. Could be in future.
Reviewers: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D52076
llvm-svn: 342449
Summary:
Factors out member decleration gathering and uses it in parsing to call signature
help. Doesn't support signature help for base class constructors, the code was too
coupled with diagnostic handling, but still can be factored out but just needs
more afford.
Reviewers: sammccall, ilya-biryukov, ioeric
Reviewed By: ilya-biryukov
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51917
llvm-svn: 341949
Summary:
Currently CodeCompleteCall only gets called after a comma or parantheses. This
patch makes sure it is called even at the cases like:
```foo(1^);```
Reviewers: ilya-biryukov, ioeric, hokein
Reviewed By: ilya-biryukov
Subscribers: MaskRay, jkorous, arphaman, cfe-commits
Differential Revision: https://reviews.llvm.org/D51038
llvm-svn: 341824
Summary:
Code completion in clang is actually a mix of two features:
- Code completion is a familiar feature. Results are exposed via the
CodeCompleteConsumer::ProcessCodeCompleteResults callback.
- Signature help figures out if the current expression is an argument of
some function call and shows corresponding signatures if so.
Results are exposed via CodeCompleteConsumer::ProcessOverloadCandidates.
This patch refactors the implementation to untangle those two from each
other and makes some naming tweaks to avoid confusion when reading the
code.
The refactoring is required for signature help fixes, see D51038.
The only intended behavior change is the order of callbacks.
ProcessOverloadCandidates is now called before ProcessCodeCompleteResults.
Reviewers: sammccall, kadircet
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D51782
llvm-svn: 341660
From a follow-up discussion in D44480.
New tests check that function bodies are not skipped:
- In presence of ptr declarators, e.g. `auto**`.
- When `decltype(auto)` is used in return type, only `auto` was checked before.
llvm-svn: 333735
Summary:
Skipping them was clearly not intentional. It's impossible to
guarantee correctness if the bodies are skipped.
Also adds a test case for r327504, now that it does not produce
invalid errors that made the test fail.
Reviewers: aaron.ballman, sammccall, rsmith
Reviewed By: rsmith
Subscribers: rayglover-ibm, rwols, cfe-commits
Differential Revision: https://reviews.llvm.org/D44480
llvm-svn: 333538
Currently getting such completions requires source correction, reparsing
and calling completion again. And if it shows no results and rollback is
required then it costs one more reparse.
With this change it's possible to get all results which can be later
filtered to split changes which require correction.
Differential Revision: https://reviews.llvm.org/D41537
llvm-svn: 333272
Summary:
The example that was broken before (^ designates completion points):
class Foo {
Foo() : fie^ld^() {} // no completions were provided here.
int field;
};
To fix it we don't cut off lexing after an identifier followed by code
completion token is lexed. Instead we skip the rest of identifier and
continue lexing.
This is consistent with behavior of completion when completion token is
right before the identifier.
Reviewers: sammccall, aaron.ballman, bkramer, sepavloff, arphaman, rsmith
Reviewed By: aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D44932
llvm-svn: 330833
Summary:
Make completion behave consistently no matter if it is run at the
start, in the middle or at the end of an identifier that happens to
be a keyword or a macro name. Since completion is often ran on
incomplete identifiers, they may turn into keywords by accident.
For example, we should produce same results for all of these
completion points:
// ^ is completion point.
^class
cla^ss
class^
Previously clang produced different results for the last case (as if
the completion point was after a space: `class ^`).
This change also updates some offsets in tests that (unintentionally?)
relied on the old behavior.
Reviewers: sammccall, bkramer, arphaman, aaron.ballman
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D45887
llvm-svn: 330717
Summary:
The relevant failing assertion message is:
../tools/clang/lib/Sema/SemaInit.cpp:8411: PerformCopyInitialization(): Assertion `InitE && "No initialization expression?"' failed.
See the added test case for a repro.
Reviewers: bkramer, sammccall, ioeric, hokein
Reviewed By: sammccall
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D44300
llvm-svn: 327134
Summary:
This patch removes IdentifierInfo from completion token after remembering
the identifier in the preprocessor.
Prior to this patch, completion token had the IdentifierInfo set to null when
completing at the start of identifier and to the II for completion prefix
when in the middle of identifier.
This patch unifies how code completion token is handled when it is insterted
before the identifier and in the middle of the identifier.
The actual IdentifierInfo can still be obtained from the Preprocessor.
Reviewers: bkramer, arphaman
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D42241
llvm-svn: 323133
This fixes PR32732 by updating CurLexerKind to reflect available lexers.
We were hitting null pointer in Preprocessor::Lex because CurLexerKind
was CLK_Lexer but CurLexer was null. And we set it to null in
Preprocessor::HandleEndOfFile when exiting a file with code completion
point.
To reproduce the crash it is important for a comment to be inside a
class specifier. In this case in Parser::ParseClassSpecifier we improve
error recovery by pushing a semicolon token back into the preprocessor
and later on try to lex a token because we haven't reached the end of
file.
Also clang crashes only on code completion in included file, i.e. when
IncludeMacroStack is not empty. Though we reset CurLexer even if include
stack is empty. The difference is that during pushing back a semicolon
token, preprocessor calls EnterCachingLexMode which decides it is
already in caching mode because various lexers are null and
IncludeMacroStack is not empty. As the result, CurLexerKind remains
CLK_Lexer instead of updating to CLK_CachingLexer.
rdar://problem/34787685
Reviewers: akyrtzi, doug.gregor, arphaman
Reviewed By: arphaman
Subscribers: cfe-commits, kfunk, arphaman, nemanjai, kbarton
Differential Revision: https://reviews.llvm.org/D41688
llvm-svn: 323008
Clang's completion output is non-deterministic, causing test failures
with turned on LLVM_REVERSE_ITERATION.
The workaround is to use CHECK-DAGs for now, will remove them when
PR35244 gets fixed.
llvm-svn: 317687
Summary:
Adjusted PrintingPolicy inside code completion to avoid printing some
redundant name qualifiers.
Before this change, typedefs that were written unqualified in source
code were printed with qualifiers in completion. For example, in the
following code
struct foo {
typedef int type;
type method();
};
completion item for `method` had return type of `foo::type`, even
though the original code used `type` without qualifiers.
After this change, the completion item has return type `type`, as
originally written in the source code.
Note that this change does not suppress qualifiers written by the
user. For example, in the following code
typedef int type;
struct foo {
typedef int type;
::type method(foo::type);
};
completion item for `method` has return type of `::type` and
parameter type of `foo::type`, as originally written in the source
code.
Reviewers: arphaman, bkramer, klimek
Reviewed By: arphaman
Subscribers: mgorny, eraman, cfe-commits
Differential Revision: https://reviews.llvm.org/D38538
llvm-svn: 317677
Summary: The crash occured when FunctionDecl was parsed with an initializer.
Reviewers: bkramer, klimek, francisco.lopes
Reviewed By: bkramer
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D37382
llvm-svn: 312788
Append optional chunks with their default values. For example:
before - "int i", after - "int i = 10"
Patch by Ivan Donchevskii!
Differential Revision: https://reviews.llvm.org/D33644
llvm-svn: 308433
This commit is a follow up to r302797 which added support for dependent
completions after the '.' and '->' operators. This commit adds support for
dependent completions after the '::' operator.
Differential Revision: https://reviews.llvm.org/D34173
llvm-svn: 305511
type is a TemplateSpecializationType or InjectedClassNameType
Fixes PR30847. Partially fixes PR20973 (first position only).
PR17614 is still not working, its expression has the dependent
builtin type. We'll have to teach the completion engine how to "resolve"
dependent expressions to fix it.
rdar://29818301
llvm-svn: 302797
If there is an unresolved member access AST node, and the base is
implicit, do not access/use it for generating candidate overloads for
code completion results.
Fixes PR31093.
llvm-svn: 298903
in macro argument pre-expansion mode when skipping a function body
This commit fixes a token caching problem that currently occurs when clang is
skipping a function body (e.g. when looking for a code completion token) and at
the same time caching the tokens for _Pragma when lexing it in macro argument
pre-expansion mode.
When _Pragma is being lexed in macro argument pre-expansion mode, it caches the
tokens so that it can avoid interpreting the pragma immediately (as the macro
argument may not be used in the macro body), and then either backtracks over or
commits these tokens. The problem is that, when we're backtracking/committing in
such a scenario, there's already a previous backtracking position stored in
BacktrackPositions (as we're skipping the function body), and this leads to a
situation where the cached tokens from the pragma (like '(' 'string_literal'
and ')') will remain in the cached tokens array incorrectly even after they're
consumed (in the case of backtracking) or just ignored (in the case when they're
committed). Furthermore, what makes it even worse, is that because of a previous
backtracking position, the logic that deals with when should we call
ExitCachingLexMode in CachingLex no longer works for us in this situation, and
more tokens in the macro argument get cached, to the point where the EOF token
that corresponds to the macro argument EOF is cached. This problem leads to all
sorts of issues in code completion mode, where incorrect errors get presented
and code completion completely fails to produce completion results.
rdar://28523863
Differential Revision: https://reviews.llvm.org/D28772
llvm-svn: 296140
This commit adds context sensitive code completion support for the C++11
keywords that currently don't have completion results.
The following keywords are supported by this patch:
alignas
constexpr
static_assert
noexcept (as a function/method qualifier)
thread_local
The following special identifiers are also supported:
final (as a method qualifier or class qualifier)
override
rdar://29219185
Differential Revision: https://reviews.llvm.org/D28286
llvm-svn: 295001
Use better heuristics to detect if a '{' might be the start of the constructor body
or not. Especially when there is a completion token.
Fix the test 'test/CodeCompletion/ctor-initializer.cpp ' when clang defaults to c++11
The problem was is how we recover invalid code in the ctor-init part as we skip the
function body. In particular, we want to know if a '{' is the begining of the body.
In C++03, we always consider it as the beginng of the body. The problem was that in
C++11, it may be the start of an initializer, so we skip over it, causing further
parse errors later. (It is important that we are able to parse correctly the rest
of the class definition, to know what are the class member, for example)
This commit is improving the heuristics to decide if the '{' is starting a function
body. The rules are the following: If we are not in a template argument, and that the
previous tokens are not an identifier, or a >, then it is much more likely to be the
function body. We verify that further by checking the token after the matching '}'
The commit also fix the behavior when there is a code_completion token in the
ctor-initializers.
Differential Revision: https://reviews.llvm.org/D21502
llvm-svn: 285883
This commit improves code completion for properties that are declared in
Objective-C protocols by making sure that properties show up in completions
when they are accessed through a qualified id.
rdar://24426041
Differential Revision: https://reviews.llvm.org/D25436
llvm-svn: 284007
- In functions with try { } catch { }, only the try block would be
skipped, not the catch blocks
- The template functions would still be parsed.
- The initializers within a constructor would still be parsed.
- The inline functions within class would still be stored, only to be
discared later.
- Invalid code with try would assert (as in "int foo() try assert_here")
This attempt to do even less while skipping function bodies.
Differential Revision: http://reviews.llvm.org/D20821
llvm-svn: 272963
This commit fixes the IdentifierIterator to actually include identifiers
from a PCH or precompiled preamble when there is also a global module
index. This was causing code-completion (outside of C++) and
typo-correction to be missing global identifiers defined in the
PCH/preamble. Typo-correction has been broken since we first started
using the module index, whereas code-completion only started relying on
identifier iterator in r232793.
rdar://problem/25642879
llvm-svn: 268471
Currently we return no results when completing inside of the brackets in
a 'char foo[]' declaration. Let the generic expression completion code
handle it instead. We could get fancier here (e.g. filter non-constant
expressions in contexts where VLAs are not allowed), but it's a strict
improvement over the existing version.
llvm-svn: 261217
Otherwise the stale module cache data may cause the test to fail. These
two tests are new and are the only instances of c-index-test with
-fmodules that doesn't have an explicit module cache path.
llvm-svn: 242710
So, iterate over the list of macros mentioned in modules, and make sure those
are in the master table.
This isn't particularly efficient, but hopefully it's something that isn't
done too often.
PR23929 and rdar://problem/21480635
llvm-svn: 240571
Various tests had sprung up over the years which had --check-prefix=ABC on the
RUN line, but "CHECK-ABC:" later on. This happened to work before, but was
strictly incorrect. FileCheck is getting stricter soon though.
Patch by Ron Ofir.
llvm-svn: 188174
Summary: Passes all tests (+ the new one with code completion), but needs a thorough review in part related to modules.
Reviewers: doug.gregor
Reviewed By: alexfh
CC: cfe-commits, rsmith
Differential Revision: http://llvm-reviews.chandlerc.com/D41
llvm-svn: 164610
attached to a declaration in the completion string.
Since extracting comments isn't free, a new code completion option is
introduced.
A new code completion option that enables including brief comments
into CodeCompletionString should be a, err, code completion option.
But because ASTUnit caches global declarations during parsing before
even completion consumer is created, the option is duplicated as a
translation unit option (in both libclang and ASTUnit, like the option
to cache code completion results).
llvm-svn: 159539
Specifically, @[] and @{} didn't have a type associated with them; we now
use "NSArray *" and "NSDictionary *", respectively. @"" has the type
"NSString *". @(), unfortunately, has type "id", since it (currently) may
be either an NSNumber or an NSString.
Add a test for all the Objective-C at-expression completions.
<rdar://problem/11507708&11507668&11507711>
llvm-svn: 158533
includes a patch from Matthias Kleine with a regression testcase!
Adds a new iterator 'data_iterator' to OnDiskHashTable which doesn't try to
reconstruct the external_key from the internal_key, which is useful for traits
that don't store enough information to do that mapping in their key. Also
deletes the 'item_iterator' from OnDiskHashTable as dead code.
llvm-svn: 154784
Previously we would cut off the source file buffer at the code-completion
point; this impeded code-completion inside C++ inline methods and,
recently, with buffering ObjC methods.
Have the code-completion inserted into the source buffer so that it can
be buffered along with a method body. When we actually hit the code-completion
point the cut-off lexing or parsing.
Fixes rdar://10056932&8319466
llvm-svn: 139086
RTTI is disabled. Similarly, don't suggest throw or try as code
completion results when C++ exceptions are disabled. Fixes
<rdar://problem/9193560>.
llvm-svn: 129346
That bug concerned the well-formedness of code such as (&ovl)(a, b,
c). GCC rejects the code, while EDG accepts it. On further study of the
standard, I see no support for EDG's position: in particular, C++
[over.over] does not list this as a context where we can take the
address of an overloaded function, C++ [over.call.func] does not
reference the address-of operator at any point, and C++ [expr.call]
claims that the function argument in a call is either a function
lvalue or a pointer-to-function; (&ovl) is neither.
llvm-svn: 118620
declaration send or a variadic function call, collapse the ", ..."
into the parameter before it, so that we don't get a second
placeholder.
llvm-svn: 112579
while we're completing in the middle of a function call), also produce
"ordinary" name results that show what can be typed at that point.
llvm-svn: 100558
therefore not creating ElaboratedTypes, which are still pretty-printed
with the written tag).
Most of these testcase changes were done by script, so don't feel too
sorry for my fingers.
llvm-svn: 98149
the "typed" text, first, then take into account
nested-name-specifiers, name hiding, etc. This means that the
resulting sort is actually alphabetical :)
llvm-svn: 93370
C++ grammatical constructs that show up in top-level (namespace-level)
declarations, member declarations, template declarations, statements,
expressions, conditions, etc. For example, we now provide a pattern
for
static_cast<type>(expr)
when we can have an expression, or
using namespace identifier;
when we can have a using directive.
Also, improves the results of code completion at the beginning of a
top-level declaration. Previously, we would see value names (function
names, global variables, etc.); now we see types, namespace names,
etc., but no values.
llvm-svn: 93134
definitions from a precompiled header. This ensures that
code-completion with macro names behaves the same with or without
precompiled headers.
llvm-svn: 92497
- This is designed to make it obvious that %clang_cc1 is a "test variable"
which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
can be useful to redefine what gets run as 'clang -cc1' (for example, to set
a default target).
llvm-svn: 91446
Ilya Biryukov