maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeCompletion/member-access.cpp

213 lines
7.8 KiB
C++
Raw Normal View History

Initial implementation of a code-completion interface in Clang. In essence, code completion is triggered by a magic "code completion" token produced by the lexer [*], which the parser recognizes at certain points in the grammar. The parser then calls into the Action object with the appropriate CodeCompletionXXX action. Sema implements the CodeCompletionXXX callbacks by performing minimal translation, then forwarding them to a CodeCompletionConsumer subclass, which uses the results of semantic analysis to provide code-completion results. At present, only a single, "printing" code completion consumer is available, for regression testing and debugging. However, the design is meant to permit other code-completion consumers. This initial commit contains two code-completion actions: one for member access, e.g., "x." or "p->", and one for nested-name-specifiers, e.g., "std::". More code-completion actions will follow, along with improved gathering of code-completion results for the various contexts. [*] In the current -code-completion-dump testing/debugging mode, the file is truncated at the completion point and EOF is translated into "code completion". llvm-svn: 82166
2009-09-18 05:32:03 +08:00
struct Base1 {
int member1;
float member2;
};
struct Base2 {
int member1;
double member3;
void memfun1(int);
};
struct Base3 : Base1, Base2 {
void memfun1(float);
Add a function's cv-qualifiers to the code-completion results as an informative chunk. llvm-svn: 91139
2009-12-12 02:44:16 +08:00
void memfun1(double) const;
Initial implementation of a code-completion interface in Clang. In essence, code completion is triggered by a magic "code completion" token produced by the lexer [*], which the parser recognizes at certain points in the grammar. The parser then calls into the Action object with the appropriate CodeCompletionXXX action. Sema implements the CodeCompletionXXX callbacks by performing minimal translation, then forwarding them to a CodeCompletionConsumer subclass, which uses the results of semantic analysis to provide code-completion results. At present, only a single, "printing" code completion consumer is available, for regression testing and debugging. However, the design is meant to permit other code-completion consumers. This initial commit contains two code-completion actions: one for member access, e.g., "x." or "p->", and one for nested-name-specifiers, e.g., "std::". More code-completion actions will follow, along with improved gathering of code-completion results for the various contexts. [*] In the current -code-completion-dump testing/debugging mode, the file is truncated at the completion point and EOF is translated into "code completion". llvm-svn: 82166
2009-09-18 05:32:03 +08:00
void memfun2(int);
};
struct Derived : Base3 {
[CodeComplete] Omit templated constructors from member list too. Also avoid printing a 'void' return type for constructor expressions. llvm-svn: 323148
2018-01-23 04:44:47 +08:00
template <typename T> Derived(T);
Derived(int);
Initial implementation of a code-completion interface in Clang. In essence, code completion is triggered by a magic "code completion" token produced by the lexer [*], which the parser recognizes at certain points in the grammar. The parser then calls into the Action object with the appropriate CodeCompletionXXX action. Sema implements the CodeCompletionXXX callbacks by performing minimal translation, then forwarding them to a CodeCompletionConsumer subclass, which uses the results of semantic analysis to provide code-completion results. At present, only a single, "printing" code completion consumer is available, for regression testing and debugging. However, the design is meant to permit other code-completion consumers. This initial commit contains two code-completion actions: one for member access, e.g., "x." or "p->", and one for nested-name-specifiers, e.g., "std::". More code-completion actions will follow, along with improved gathering of code-completion results for the various contexts. [*] In the current -code-completion-dump testing/debugging mode, the file is truncated at the completion point and EOF is translated into "code completion". llvm-svn: 82166
2009-09-18 05:32:03 +08:00
int member4;
int memfun3(int);
};
class Proxy {
public:
Derived *operator->() const;
};
void test(const Proxy &p) {
Replace the -code-completion-dump option with -code-completion-at=filename:line:column which performs code completion at the specified location by truncating the file at that position and enabling code completion. This approach makes it possible to run multiple tests from a single test file, and gives a more natural command-line interface. llvm-svn: 82571
2009-09-23 05:11:38 +08:00
p->
[code-completion] Fix crash when trying to do postfix completion of instance member inside a static function. llvm-svn: 292052
2017-01-15 14:11:04 +08:00
}
struct Test1 {
Base1 b;
static void sfunc() {
b. // expected-error {{invalid use of member 'b' in static member function}}
}
};
[libclang] Fix crash in member access code completion with implicit base 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
2017-03-28 15:22:21 +08:00
struct Foo {
void foo() const;
static void foo(bool);
};
struct Bar {
void foo(bool param) {
Foo::foo( );// unresolved member expression with an implicit base
}
};
[CodeComplete] Omit templated constructors from member list too. Also avoid printing a 'void' return type for constructor expressions. llvm-svn: 323148
2018-01-23 04:44:47 +08:00
// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:31:6 %s -o - | FileCheck -check-prefix=CHECK-CC1 --implicit-check-not="Derived : Derived(" %s
[CodeComplete] Expose InBaseClass signal in code completion results. 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
2018-10-24 20:57:27 +08:00
// CHECK-CC1: Base1 (InBase) : Base1::
// CHECK-CC1: member1 (InBase) : [#int#][#Base1::#]member1
// CHECK-CC1: member1 (InBase) : [#int#][#Base2::#]member1
// CHECK-CC1: member2 (InBase) : [#float#][#Base1::#]member2
// CHECK-CC1: member3 (InBase)
Improve the sorting of code-completion results. We now always sort by 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
2010-01-14 07:24:38 +08:00
// CHECK-CC1: member4
[CodeComplete] Expose InBaseClass signal in code completion results. 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
2018-10-24 20:57:27 +08:00
// CHECK-CC1: memfun1 (InBase) : [#void#][#Base3::#]memfun1(<#float#>)
// CHECK-CC1: memfun1 (InBase) : [#void#][#Base3::#]memfun1(<#double#>)[# const#]
// CHECK-CC1: memfun1 (Hidden,InBase) : [#void#]Base2::memfun1(<#int#>)
// CHECK-CC1: memfun2 (InBase) : [#void#][#Base3::#]memfun2(<#int#>)
Improve the sorting of code-completion results. We now always sort by 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
2010-01-14 07:24:38 +08:00
// CHECK-CC1: memfun3 : [#int#]memfun3(<#int#>)
[code-completion] Fix crash when trying to do postfix completion of instance member inside a static function. llvm-svn: 292052
2017-01-15 14:11:04 +08:00
// Make sure this doesn't crash
[CodeComplete] Omit templated constructors from member list too. Also avoid printing a 'void' return type for constructor expressions. llvm-svn: 323148
2018-01-23 04:44:47 +08:00
// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:38:7 %s -verify
[libclang] Fix crash in member access code completion with implicit base 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
2017-03-28 15:22:21 +08:00
// Make sure this also doesn't crash
[CodeComplete] Omit templated constructors from member list too. Also avoid printing a 'void' return type for constructor expressions. llvm-svn: 323148
2018-01-23 04:44:47 +08:00
// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:49:14 %s
[CodeCompletion] Provide member completions for dependent expressions whose 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
2017-05-11 21:48:57 +08:00
template<typename T>
class BaseTemplate {
public:
T baseTemplateFunction();
T baseTemplateField;
};
template<typename T, typename S>
class TemplateClass: public Base1 , public BaseTemplate<T> {
public:
T function() { }
T field;
void overload1(const T &);
void overload1(const S &);
};
template<typename T, typename S>
void completeDependentMembers(TemplateClass<T, S> &object,
TemplateClass<int, S> *object2) {
object.field;
object2->field;
[CodeComplete] Expose InBaseClass signal in code completion results. 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
2018-10-24 20:57:27 +08:00
// CHECK-CC2: baseTemplateField (InBase) : [#T#][#BaseTemplate<T>::#]baseTemplateField
// CHECK-CC2: baseTemplateFunction (InBase) : [#T#][#BaseTemplate<T>::#]baseTemplateFunction()
[CodeCompletion] Provide member completions for dependent expressions whose 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
2017-05-11 21:48:57 +08:00
// CHECK-CC2: field : [#T#]field
// CHECK-CC2: function : [#T#]function()
[CodeComplete] Expose InBaseClass signal in code completion results. 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
2018-10-24 20:57:27 +08:00
// CHECK-CC2: member1 (InBase) : [#int#][#Base1::#]member1
// CHECK-CC2: member2 (InBase) : [#float#][#Base1::#]member2
[CodeCompletion] Provide member completions for dependent expressions whose 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
2017-05-11 21:48:57 +08:00
// CHECK-CC2: overload1 : [#void#]overload1(<#const T &#>)
// CHECK-CC2: overload1 : [#void#]overload1(<#const S &#>)
[CodeComplete] Omit templated constructors from member list too. Also avoid printing a 'void' return type for constructor expressions. llvm-svn: 323148
2018-01-23 04:44:47 +08:00
// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:94:10 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:95:12 %s -o - | FileCheck -check-prefix=CHECK-CC2 %s
[CodeCompletion] Provide member completions for dependent expressions whose 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
2017-05-11 21:48:57 +08:00
}
void completeDependentSpecializedMembers(TemplateClass<int, double> &object,
TemplateClass<int, double> *object2) {
object.field;
object2->field;
[CodeComplete] Expose InBaseClass signal in code completion results. 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
2018-10-24 20:57:27 +08:00
// CHECK-CC3: baseTemplateField (InBase) : [#int#][#BaseTemplate<int>::#]baseTemplateField
// CHECK-CC3: baseTemplateFunction (InBase) : [#int#][#BaseTemplate<int>::#]baseTemplateFunction()
[CodeCompletion] Provide member completions for dependent expressions whose 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
2017-05-11 21:48:57 +08:00
// CHECK-CC3: field : [#int#]field
// CHECK-CC3: function : [#int#]function()
[CodeComplete] Expose InBaseClass signal in code completion results. 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
2018-10-24 20:57:27 +08:00
// CHECK-CC3: member1 (InBase) : [#int#][#Base1::#]member1
// CHECK-CC3: member2 (InBase) : [#float#][#Base1::#]member2
[CodeCompletion] Provide member completions for dependent expressions whose 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
2017-05-11 21:48:57 +08:00
// CHECK-CC3: overload1 : [#void#]overload1(<#const int &#>)
// CHECK-CC3: overload1 : [#void#]overload1(<#const double &#>)
[CodeComplete] Omit templated constructors from member list too. Also avoid printing a 'void' return type for constructor expressions. llvm-svn: 323148
2018-01-23 04:44:47 +08:00
// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:112:10 %s -o - | FileCheck -check-prefix=CHECK-CC3 %s
// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:113:12 %s -o - | FileCheck -check-prefix=CHECK-CC3 %s
[CodeCompletion] Provide member completions for dependent expressions whose 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
2017-05-11 21:48:57 +08:00
}
template <typename T>
class Template {
public:
BaseTemplate<int> o1;
BaseTemplate<T> o2;
void function() {
o1.baseTemplateField;
// CHECK-CC4: BaseTemplate : BaseTemplate::
// CHECK-CC4: baseTemplateField : [#int#]baseTemplateField
// CHECK-CC4: baseTemplateFunction : [#int#]baseTemplateFunction()
[CodeComplete] Omit templated constructors from member list too. Also avoid printing a 'void' return type for constructor expressions. llvm-svn: 323148
2018-01-23 04:44:47 +08:00
// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:134:8 %s -o - | FileCheck -check-prefix=CHECK-CC4 %s
[CodeCompletion] Provide member completions for dependent expressions whose 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
2017-05-11 21:48:57 +08:00
o2.baseTemplateField;
// CHECK-CC5: BaseTemplate : BaseTemplate::
// CHECK-CC5: baseTemplateField : [#T#]baseTemplateField
// CHECK-CC5: baseTemplateFunction : [#T#]baseTemplateFunction()
[CodeComplete] Omit templated constructors from member list too. Also avoid printing a 'void' return type for constructor expressions. llvm-svn: 323148
2018-01-23 04:44:47 +08:00
// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:139:8 %s -o - | FileCheck -check-prefix=CHECK-CC5 %s
[CodeCompletion] Provide member completions for dependent expressions whose 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
2017-05-11 21:48:57 +08:00
this->o1;
// CHECK-CC6: [#void#]function()
// CHECK-CC6: o1 : [#BaseTemplate<int>#]o1
// CHECK-CC6: o2 : [#BaseTemplate<T>#]o2
[CodeComplete] Omit templated constructors from member list too. Also avoid printing a 'void' return type for constructor expressions. llvm-svn: 323148
2018-01-23 04:44:47 +08:00
// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:144:11 %s -o - | FileCheck -check-prefix=CHECK-CC6 %s
[CodeCompletion] Provide member completions for dependent expressions whose 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
2017-05-11 21:48:57 +08:00
}
[Completion] Code complete the members for a dependent type after a '::' 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
2017-06-16 05:40:54 +08:00
static void staticFn(T &obj);
struct Nested { };
[CodeCompletion] Provide member completions for dependent expressions whose 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
2017-05-11 21:48:57 +08:00
};
[Completion] Code complete the members for a dependent type after a '::' 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
2017-06-16 05:40:54 +08:00
template<typename T>
void dependentColonColonCompletion() {
Template<T>::staticFn();
// CHECK-CC7: function : [#void#]function()
// CHECK-CC7: Nested : Nested
// CHECK-CC7: o1 : [#BaseTemplate<int>#]o1
// CHECK-CC7: o2 : [#BaseTemplate<T>#]o2
// CHECK-CC7: staticFn : [#void#]staticFn(<#T &obj#>)
// CHECK-CC7: Template : Template
[CodeComplete] Omit templated constructors from member list too. Also avoid printing a 'void' return type for constructor expressions. llvm-svn: 323148
2018-01-23 04:44:47 +08:00
// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:158:16 %s -o - | FileCheck -check-prefix=CHECK-CC7 %s
[Completion] Code complete the members for a dependent type after a '::' 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
2017-06-16 05:40:54 +08:00
typename Template<T>::Nested m;
[CodeComplete] Omit templated constructors from member list too. Also avoid printing a 'void' return type for constructor expressions. llvm-svn: 323148
2018-01-23 04:44:47 +08:00
// RUN: %clang_cc1 -fsyntax-only -code-completion-at=%s:166:25 %s -o - | FileCheck -check-prefix=CHECK-CC7 %s
[Completion] Code complete the members for a dependent type after a '::' 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
2017-06-16 05:40:54 +08:00
}
Optionally add code completion results for arrow instead of dot 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
2018-05-25 20:56:26 +08:00
class Proxy2 {
public:
Derived *operator->() const;
int member5;
};
void test2(const Proxy2 &p) {
p->
}
void test3(const Proxy2 &p) {
p.
}
// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits -code-completion-at=%s:177:6 %s -o - | FileCheck -check-prefix=CHECK-CC8 --implicit-check-not="Derived : Derived(" %s
[CodeComplete] Expose InBaseClass signal in code completion results. 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
2018-10-24 20:57:27 +08:00
// CHECK-CC8: Base1 (InBase) : Base1::
// CHECK-CC8: member1 (InBase) : [#int#][#Base1::#]member1
// CHECK-CC8: member1 (InBase) : [#int#][#Base2::#]member1
// CHECK-CC8: member2 (InBase) : [#float#][#Base1::#]member2
// CHECK-CC8: member3 (InBase) : [#double#][#Base2::#]member3
Optionally add code completion results for arrow instead of dot 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
2018-05-25 20:56:26 +08:00
// CHECK-CC8: member4 : [#int#]member4
// CHECK-CC8: member5 : [#int#]member5 (requires fix-it: {177:4-177:6} to ".")
[CodeComplete] Expose InBaseClass signal in code completion results. 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
2018-10-24 20:57:27 +08:00
// CHECK-CC8: memfun1 (InBase) : [#void#][#Base3::#]memfun1(<#float#>)
// CHECK-CC8: memfun1 (InBase) : [#void#][#Base3::#]memfun1(<#double#>)[# const#]
// CHECK-CC8: memfun1 (Hidden,InBase) : [#void#]Base2::memfun1(<#int#>)
// CHECK-CC8: memfun2 (InBase) : [#void#][#Base3::#]memfun2(<#int#>)
Optionally add code completion results for arrow instead of dot 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
2018-05-25 20:56:26 +08:00
// CHECK-CC8: memfun3 : [#int#]memfun3(<#int#>)
// CHECK-CC8: operator-> : [#Derived *#]operator->()[# const#] (requires fix-it: {177:4-177:6} to ".")
// RUN: %clang_cc1 -fsyntax-only -code-completion-with-fixits -code-completion-at=%s:181:6 %s -o - | FileCheck -check-prefix=CHECK-CC9 --implicit-check-not="Derived : Derived(" %s
[CodeComplete] Expose InBaseClass signal in code completion results. 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
2018-10-24 20:57:27 +08:00
// CHECK-CC9: Base1 (InBase) : Base1::
// CHECK-CC9: member1 (InBase) : [#int#][#Base1::#]member1 (requires fix-it: {181:4-181:5} to "->")
// CHECK-CC9: member1 (InBase) : [#int#][#Base2::#]member1 (requires fix-it: {181:4-181:5} to "->")
// CHECK-CC9: member2 (InBase) : [#float#][#Base1::#]member2 (requires fix-it: {181:4-181:5} to "->")
// CHECK-CC9: member3 (InBase) : [#double#][#Base2::#]member3 (requires fix-it: {181:4-181:5} to "->")
Optionally add code completion results for arrow instead of dot 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
2018-05-25 20:56:26 +08:00
// CHECK-CC9: member4 : [#int#]member4 (requires fix-it: {181:4-181:5} to "->")
// CHECK-CC9: member5 : [#int#]member5
[CodeComplete] Expose InBaseClass signal in code completion results. 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
2018-10-24 20:57:27 +08:00
// CHECK-CC9: memfun1 (InBase) : [#void#][#Base3::#]memfun1(<#float#>) (requires fix-it: {181:4-181:5} to "->")
// CHECK-CC9: memfun1 (InBase) : [#void#][#Base3::#]memfun1(<#double#>)[# const#] (requires fix-it: {181:4-181:5} to "->")
// CHECK-CC9: memfun1 (Hidden,InBase) : [#void#]Base2::memfun1(<#int#>) (requires fix-it: {181:4-181:5} to "->")
// CHECK-CC9: memfun2 (InBase) : [#void#][#Base3::#]memfun2(<#int#>) (requires fix-it: {181:4-181:5} to "->")
Optionally add code completion results for arrow instead of dot 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
2018-05-25 20:56:26 +08:00
// CHECK-CC9: memfun3 : [#int#]memfun3(<#int#>) (requires fix-it: {181:4-181:5} to "->")
// CHECK-CC9: operator-> : [#Derived *#]operator->()[# const#]