2009-09-22 00:56:56 +08:00
|
|
|
//===--- CodeCompleteConsumer.cpp - Code Completion Interface ---*- C++ -*-===//
|
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
|
|
|
//
|
|
|
|
// The LLVM Compiler Infrastructure
|
|
|
|
//
|
|
|
|
// This file is distributed under the University of Illinois Open Source
|
|
|
|
// License. See LICENSE.TXT for details.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
//
|
|
|
|
// This file implements the CodeCompleteConsumer class.
|
|
|
|
//
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
#include "clang/Sema/CodeCompleteConsumer.h"
|
2010-08-21 02:27:03 +08:00
|
|
|
#include "clang/Sema/Scope.h"
|
2010-08-13 04:07:10 +08:00
|
|
|
#include "clang/Sema/Sema.h"
|
2009-09-19 01:54:00 +08:00
|
|
|
#include "clang/AST/DeclCXX.h"
|
2010-08-24 15:21:54 +08:00
|
|
|
#include "clang/AST/DeclObjC.h"
|
2010-08-25 13:32:35 +08:00
|
|
|
#include "clang/AST/DeclTemplate.h"
|
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
|
|
|
#include "clang/Lex/Preprocessor.h"
|
2009-12-01 13:55:20 +08:00
|
|
|
#include "clang-c/Index.h"
|
2012-02-04 21:45:25 +08:00
|
|
|
#include "llvm/ADT/SmallString.h"
|
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
|
|
|
#include "llvm/ADT/STLExtras.h"
|
2011-02-17 08:22:45 +08:00
|
|
|
#include "llvm/ADT/Twine.h"
|
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
|
|
|
#include "llvm/Support/raw_ostream.h"
|
|
|
|
#include <algorithm>
|
2009-09-19 06:15:54 +08:00
|
|
|
#include <cstring>
|
|
|
|
#include <functional>
|
2009-11-18 00:43:05 +08:00
|
|
|
|
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
|
|
|
using namespace clang;
|
|
|
|
|
2010-09-22 00:06:22 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Code completion context implementation
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
bool CodeCompletionContext::wantConstructorResults() const {
|
|
|
|
switch (Kind) {
|
2010-09-24 07:01:17 +08:00
|
|
|
case CCC_Recovery:
|
2010-09-22 00:06:22 +08:00
|
|
|
case CCC_Statement:
|
|
|
|
case CCC_Expression:
|
|
|
|
case CCC_ObjCMessageReceiver:
|
|
|
|
case CCC_ParenthesizedExpression:
|
|
|
|
return true;
|
|
|
|
|
|
|
|
case CCC_TopLevel:
|
|
|
|
case CCC_ObjCInterface:
|
|
|
|
case CCC_ObjCImplementation:
|
|
|
|
case CCC_ObjCIvarList:
|
|
|
|
case CCC_ClassStructUnion:
|
2011-07-08 00:03:39 +08:00
|
|
|
case CCC_DotMemberAccess:
|
|
|
|
case CCC_ArrowMemberAccess:
|
|
|
|
case CCC_ObjCPropertyAccess:
|
2010-09-22 00:06:22 +08:00
|
|
|
case CCC_EnumTag:
|
|
|
|
case CCC_UnionTag:
|
|
|
|
case CCC_ClassOrStructTag:
|
|
|
|
case CCC_ObjCProtocolName:
|
|
|
|
case CCC_Namespace:
|
|
|
|
case CCC_Type:
|
|
|
|
case CCC_Name:
|
|
|
|
case CCC_PotentiallyQualifiedName:
|
|
|
|
case CCC_MacroName:
|
|
|
|
case CCC_MacroNameUse:
|
|
|
|
case CCC_PreprocessorExpression:
|
|
|
|
case CCC_PreprocessorDirective:
|
|
|
|
case CCC_NaturalLanguage:
|
|
|
|
case CCC_SelectorName:
|
|
|
|
case CCC_TypeQualifiers:
|
2010-09-24 07:01:17 +08:00
|
|
|
case CCC_Other:
|
2011-02-19 07:30:37 +08:00
|
|
|
case CCC_OtherWithMacros:
|
2011-07-08 00:03:39 +08:00
|
|
|
case CCC_ObjCInstanceMessage:
|
|
|
|
case CCC_ObjCClassMessage:
|
2011-07-30 14:55:39 +08:00
|
|
|
case CCC_ObjCInterfaceName:
|
2011-07-08 00:03:39 +08:00
|
|
|
case CCC_ObjCCategoryName:
|
2010-09-22 00:06:22 +08:00
|
|
|
return false;
|
|
|
|
}
|
2012-01-17 14:56:22 +08:00
|
|
|
|
|
|
|
llvm_unreachable("Invalid CodeCompletionContext::Kind!");
|
2010-09-22 00:06:22 +08:00
|
|
|
}
|
|
|
|
|
2009-09-19 06:15:54 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Code completion string implementation
|
|
|
|
//===----------------------------------------------------------------------===//
|
2011-02-02 03:23:04 +08:00
|
|
|
CodeCompletionString::Chunk::Chunk(ChunkKind Kind, const char *Text)
|
2009-11-13 02:40:12 +08:00
|
|
|
: Kind(Kind), Text("")
|
2009-09-23 07:15:58 +08:00
|
|
|
{
|
2009-11-07 08:00:49 +08:00
|
|
|
switch (Kind) {
|
|
|
|
case CK_TypedText:
|
|
|
|
case CK_Text:
|
|
|
|
case CK_Placeholder:
|
|
|
|
case CK_Informative:
|
2009-12-19 02:53:37 +08:00
|
|
|
case CK_ResultType:
|
2011-02-02 03:23:04 +08:00
|
|
|
case CK_CurrentParameter:
|
|
|
|
this->Text = Text;
|
2009-11-07 08:00:49 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_Optional:
|
2009-12-12 13:05:38 +08:00
|
|
|
llvm_unreachable("Optional strings cannot be created from text");
|
2009-11-07 08:00:49 +08:00
|
|
|
|
|
|
|
case CK_LeftParen:
|
|
|
|
this->Text = "(";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_RightParen:
|
|
|
|
this->Text = ")";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_LeftBracket:
|
|
|
|
this->Text = "[";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_RightBracket:
|
|
|
|
this->Text = "]";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_LeftBrace:
|
|
|
|
this->Text = "{";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_RightBrace:
|
|
|
|
this->Text = "}";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_LeftAngle:
|
|
|
|
this->Text = "<";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_RightAngle:
|
|
|
|
this->Text = ">";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_Comma:
|
|
|
|
this->Text = ", ";
|
|
|
|
break;
|
Improve code completion by introducing patterns for the various C and
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
2010-01-11 07:08:15 +08:00
|
|
|
|
|
|
|
case CK_Colon:
|
2010-04-07 08:21:17 +08:00
|
|
|
this->Text = ":";
|
Improve code completion by introducing patterns for the various C and
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
2010-01-11 07:08:15 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_SemiColon:
|
|
|
|
this->Text = ";";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_Equal:
|
|
|
|
this->Text = " = ";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_HorizontalSpace:
|
|
|
|
this->Text = " ";
|
|
|
|
break;
|
|
|
|
|
|
|
|
case CK_VerticalSpace:
|
|
|
|
this->Text = "\n";
|
|
|
|
break;
|
2009-11-07 08:00:49 +08:00
|
|
|
}
|
2009-09-23 07:15:58 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
CodeCompletionString::Chunk
|
2011-02-02 03:23:04 +08:00
|
|
|
CodeCompletionString::Chunk::CreateText(const char *Text) {
|
2009-09-23 07:15:58 +08:00
|
|
|
return Chunk(CK_Text, Text);
|
2009-09-19 06:15:54 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
CodeCompletionString::Chunk
|
2011-02-02 03:23:04 +08:00
|
|
|
CodeCompletionString::Chunk::CreateOptional(CodeCompletionString *Optional) {
|
2009-09-19 06:15:54 +08:00
|
|
|
Chunk Result;
|
|
|
|
Result.Kind = CK_Optional;
|
2011-02-02 03:23:04 +08:00
|
|
|
Result.Optional = Optional;
|
2009-09-19 06:15:54 +08:00
|
|
|
return Result;
|
|
|
|
}
|
|
|
|
|
|
|
|
CodeCompletionString::Chunk
|
2011-02-02 03:23:04 +08:00
|
|
|
CodeCompletionString::Chunk::CreatePlaceholder(const char *Placeholder) {
|
2009-09-23 07:15:58 +08:00
|
|
|
return Chunk(CK_Placeholder, Placeholder);
|
|
|
|
}
|
|
|
|
|
|
|
|
CodeCompletionString::Chunk
|
2011-02-02 03:23:04 +08:00
|
|
|
CodeCompletionString::Chunk::CreateInformative(const char *Informative) {
|
2009-09-23 07:15:58 +08:00
|
|
|
return Chunk(CK_Informative, Informative);
|
2009-09-19 06:15:54 +08:00
|
|
|
}
|
|
|
|
|
2009-12-19 02:53:37 +08:00
|
|
|
CodeCompletionString::Chunk
|
2011-02-02 03:23:04 +08:00
|
|
|
CodeCompletionString::Chunk::CreateResultType(const char *ResultType) {
|
2009-12-19 02:53:37 +08:00
|
|
|
return Chunk(CK_ResultType, ResultType);
|
|
|
|
}
|
|
|
|
|
2009-11-07 08:00:49 +08:00
|
|
|
CodeCompletionString::Chunk
|
|
|
|
CodeCompletionString::Chunk::CreateCurrentParameter(
|
2011-02-02 03:23:04 +08:00
|
|
|
const char *CurrentParameter) {
|
2009-11-07 08:00:49 +08:00
|
|
|
return Chunk(CK_CurrentParameter, CurrentParameter);
|
|
|
|
}
|
|
|
|
|
2011-02-02 03:23:04 +08:00
|
|
|
CodeCompletionString::CodeCompletionString(const Chunk *Chunks,
|
|
|
|
unsigned NumChunks,
|
|
|
|
unsigned Priority,
|
2011-10-14 23:31:08 +08:00
|
|
|
CXAvailabilityKind Availability,
|
|
|
|
const char **Annotations,
|
|
|
|
unsigned NumAnnotations)
|
|
|
|
: NumChunks(NumChunks), NumAnnotations(NumAnnotations)
|
|
|
|
, Priority(Priority), Availability(Availability)
|
2011-02-02 03:23:04 +08:00
|
|
|
{
|
2011-10-14 23:31:08 +08:00
|
|
|
assert(NumChunks <= 0xffff);
|
|
|
|
assert(NumAnnotations <= 0xffff);
|
|
|
|
|
2011-02-02 03:23:04 +08:00
|
|
|
Chunk *StoredChunks = reinterpret_cast<Chunk *>(this + 1);
|
|
|
|
for (unsigned I = 0; I != NumChunks; ++I)
|
|
|
|
StoredChunks[I] = Chunks[I];
|
2011-10-14 23:31:08 +08:00
|
|
|
|
|
|
|
const char **StoredAnnotations = reinterpret_cast<const char **>(StoredChunks + NumChunks);
|
|
|
|
for (unsigned I = 0; I != NumAnnotations; ++I)
|
|
|
|
StoredAnnotations[I] = Annotations[I];
|
|
|
|
}
|
|
|
|
|
|
|
|
unsigned CodeCompletionString::getAnnotationCount() const {
|
|
|
|
return NumAnnotations;
|
2009-09-19 06:15:54 +08:00
|
|
|
}
|
|
|
|
|
2011-10-14 23:31:08 +08:00
|
|
|
const char *CodeCompletionString::getAnnotation(unsigned AnnotationNr) const {
|
|
|
|
if (AnnotationNr < NumAnnotations)
|
|
|
|
return reinterpret_cast<const char * const*>(end())[AnnotationNr];
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
|
2009-09-19 06:15:54 +08:00
|
|
|
std::string CodeCompletionString::getAsString() const {
|
|
|
|
std::string Result;
|
|
|
|
llvm::raw_string_ostream OS(Result);
|
|
|
|
|
|
|
|
for (iterator C = begin(), CEnd = end(); C != CEnd; ++C) {
|
|
|
|
switch (C->Kind) {
|
|
|
|
case CK_Optional: OS << "{#" << C->Optional->getAsString() << "#}"; break;
|
2009-09-23 07:15:58 +08:00
|
|
|
case CK_Placeholder: OS << "<#" << C->Text << "#>"; break;
|
2009-12-19 02:53:37 +08:00
|
|
|
|
|
|
|
case CK_Informative:
|
|
|
|
case CK_ResultType:
|
|
|
|
OS << "[#" << C->Text << "#]";
|
|
|
|
break;
|
|
|
|
|
2009-11-07 08:00:49 +08:00
|
|
|
case CK_CurrentParameter: OS << "<#" << C->Text << "#>"; break;
|
|
|
|
default: OS << C->Text; break;
|
2009-09-19 06:15:54 +08:00
|
|
|
}
|
|
|
|
}
|
2010-07-27 05:33:22 +08:00
|
|
|
return OS.str();
|
2009-09-19 06:15:54 +08:00
|
|
|
}
|
|
|
|
|
2009-11-19 08:01:57 +08:00
|
|
|
const char *CodeCompletionString::getTypedText() const {
|
|
|
|
for (iterator C = begin(), CEnd = end(); C != CEnd; ++C)
|
|
|
|
if (C->Kind == CK_TypedText)
|
|
|
|
return C->Text;
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2011-07-23 18:55:15 +08:00
|
|
|
const char *CodeCompletionAllocator::CopyString(StringRef String) {
|
2011-02-02 06:57:45 +08:00
|
|
|
char *Mem = (char *)Allocate(String.size() + 1, 1);
|
|
|
|
std::copy(String.begin(), String.end(), Mem);
|
|
|
|
Mem[String.size()] = 0;
|
|
|
|
return Mem;
|
|
|
|
}
|
|
|
|
|
2011-07-23 18:55:15 +08:00
|
|
|
const char *CodeCompletionAllocator::CopyString(Twine String) {
|
2011-02-17 08:22:45 +08:00
|
|
|
// FIXME: It would be more efficient to teach Twine to tell us its size and
|
|
|
|
// then add a routine there to fill in an allocated char* with the contents
|
|
|
|
// of the string.
|
2012-02-05 10:13:05 +08:00
|
|
|
SmallString<128> Data;
|
2011-02-17 08:22:45 +08:00
|
|
|
return CopyString(String.toStringRef(Data));
|
|
|
|
}
|
|
|
|
|
2011-02-02 03:23:04 +08:00
|
|
|
CodeCompletionString *CodeCompletionBuilder::TakeString() {
|
|
|
|
void *Mem = Allocator.Allocate(
|
2011-10-14 23:31:08 +08:00
|
|
|
sizeof(CodeCompletionString) + sizeof(Chunk) * Chunks.size()
|
|
|
|
+ sizeof(const char *) * Annotations.size(),
|
2011-02-02 03:23:04 +08:00
|
|
|
llvm::alignOf<CodeCompletionString>());
|
|
|
|
CodeCompletionString *Result
|
|
|
|
= new (Mem) CodeCompletionString(Chunks.data(), Chunks.size(),
|
2011-10-14 23:31:08 +08:00
|
|
|
Priority, Availability,
|
|
|
|
Annotations.data(), Annotations.size());
|
2011-02-02 03:23:04 +08:00
|
|
|
Chunks.clear();
|
2009-11-19 08:01:57 +08:00
|
|
|
return Result;
|
|
|
|
}
|
2009-11-07 08:00:49 +08:00
|
|
|
|
2010-08-25 14:19:51 +08:00
|
|
|
unsigned CodeCompletionResult::getPriorityFromDecl(NamedDecl *ND) {
|
2010-05-27 06:00:08 +08:00
|
|
|
if (!ND)
|
|
|
|
return CCP_Unlikely;
|
|
|
|
|
|
|
|
// Context-based decisions.
|
2010-08-31 08:36:30 +08:00
|
|
|
DeclContext *DC = ND->getDeclContext()->getRedeclContext();
|
2010-09-18 23:16:27 +08:00
|
|
|
if (DC->isFunctionOrMethod() || isa<BlockDecl>(DC)) {
|
|
|
|
// _cmd is relatively rare
|
|
|
|
if (ImplicitParamDecl *ImplicitParam = dyn_cast<ImplicitParamDecl>(ND))
|
|
|
|
if (ImplicitParam->getIdentifier() &&
|
|
|
|
ImplicitParam->getIdentifier()->isStr("_cmd"))
|
|
|
|
return CCP_ObjC_cmd;
|
|
|
|
|
2010-05-27 06:00:08 +08:00
|
|
|
return CCP_LocalDeclaration;
|
2010-09-18 23:16:27 +08:00
|
|
|
}
|
2010-05-27 06:00:08 +08:00
|
|
|
if (DC->isRecord() || isa<ObjCContainerDecl>(DC))
|
|
|
|
return CCP_MemberDeclaration;
|
|
|
|
|
|
|
|
// Content-based decisions.
|
|
|
|
if (isa<EnumConstantDecl>(ND))
|
|
|
|
return CCP_Constant;
|
|
|
|
if (isa<TypeDecl>(ND) || isa<ObjCInterfaceDecl>(ND))
|
|
|
|
return CCP_Type;
|
2010-09-18 23:16:27 +08:00
|
|
|
|
2010-05-27 06:00:08 +08:00
|
|
|
return CCP_Declaration;
|
|
|
|
}
|
|
|
|
|
2009-09-23 08:16:58 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Code completion overload candidate implementation
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
FunctionDecl *
|
|
|
|
CodeCompleteConsumer::OverloadCandidate::getFunction() const {
|
|
|
|
if (getKind() == CK_Function)
|
|
|
|
return Function;
|
|
|
|
else if (getKind() == CK_FunctionTemplate)
|
|
|
|
return FunctionTemplate->getTemplatedDecl();
|
|
|
|
else
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
const FunctionType *
|
|
|
|
CodeCompleteConsumer::OverloadCandidate::getFunctionType() const {
|
|
|
|
switch (Kind) {
|
|
|
|
case CK_Function:
|
|
|
|
return Function->getType()->getAs<FunctionType>();
|
|
|
|
|
|
|
|
case CK_FunctionTemplate:
|
|
|
|
return FunctionTemplate->getTemplatedDecl()->getType()
|
|
|
|
->getAs<FunctionType>();
|
|
|
|
|
|
|
|
case CK_FunctionType:
|
|
|
|
return Type;
|
|
|
|
}
|
2012-01-17 14:56:22 +08:00
|
|
|
|
|
|
|
llvm_unreachable("Invalid CandidateKind!");
|
2009-09-23 08:16:58 +08:00
|
|
|
}
|
|
|
|
|
2009-09-19 06:15:54 +08:00
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
// Code completion consumer implementation
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
2009-09-22 00:56:56 +08:00
|
|
|
CodeCompleteConsumer::~CodeCompleteConsumer() { }
|
2009-09-19 06:15:54 +08:00
|
|
|
|
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
|
2009-11-13 16:58:20 +08:00
|
|
|
PrintingCodeCompleteConsumer::ProcessCodeCompleteResults(Sema &SemaRef,
|
2010-08-12 05:23:17 +08:00
|
|
|
CodeCompletionContext Context,
|
2010-08-25 14:19:51 +08:00
|
|
|
CodeCompletionResult *Results,
|
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
|
|
|
unsigned NumResults) {
|
2010-08-26 21:48:20 +08:00
|
|
|
std::stable_sort(Results, Results + NumResults);
|
|
|
|
|
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
|
|
|
// Print the results.
|
|
|
|
for (unsigned I = 0; I != NumResults; ++I) {
|
2009-10-10 06:16:47 +08:00
|
|
|
OS << "COMPLETION: ";
|
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
|
|
|
switch (Results[I].Kind) {
|
2010-08-25 14:19:51 +08:00
|
|
|
case CodeCompletionResult::RK_Declaration:
|
2011-10-15 02:45:37 +08:00
|
|
|
OS << *Results[I].Declaration;
|
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
|
|
|
if (Results[I].Hidden)
|
|
|
|
OS << " (Hidden)";
|
2009-09-22 00:56:56 +08:00
|
|
|
if (CodeCompletionString *CCS
|
2011-02-02 03:23:04 +08:00
|
|
|
= Results[I].CreateCodeCompletionString(SemaRef, Allocator)) {
|
2009-09-19 06:15:54 +08:00
|
|
|
OS << " : " << CCS->getAsString();
|
|
|
|
}
|
|
|
|
|
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
|
|
|
OS << '\n';
|
|
|
|
break;
|
|
|
|
|
2010-08-25 14:19:51 +08:00
|
|
|
case CodeCompletionResult::RK_Keyword:
|
2010-01-14 07:24:38 +08:00
|
|
|
OS << Results[I].Keyword << '\n';
|
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
|
|
|
break;
|
2009-10-31 00:50:04 +08:00
|
|
|
|
2010-08-25 14:19:51 +08:00
|
|
|
case CodeCompletionResult::RK_Macro: {
|
2010-01-14 07:24:38 +08:00
|
|
|
OS << Results[I].Macro->getName();
|
2009-10-31 00:50:04 +08:00
|
|
|
if (CodeCompletionString *CCS
|
2011-02-02 03:23:04 +08:00
|
|
|
= Results[I].CreateCodeCompletionString(SemaRef, Allocator)) {
|
2009-10-31 00:50:04 +08:00
|
|
|
OS << " : " << CCS->getAsString();
|
|
|
|
}
|
|
|
|
OS << '\n';
|
|
|
|
break;
|
|
|
|
}
|
2009-11-19 08:01:57 +08:00
|
|
|
|
2010-08-25 14:19:51 +08:00
|
|
|
case CodeCompletionResult::RK_Pattern: {
|
2010-01-14 07:24:38 +08:00
|
|
|
OS << "Pattern : "
|
2009-11-19 08:01:57 +08:00
|
|
|
<< Results[I].Pattern->getAsString() << '\n';
|
|
|
|
break;
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2009-09-23 08:16:58 +08:00
|
|
|
|
|
|
|
void
|
2009-11-13 16:58:20 +08:00
|
|
|
PrintingCodeCompleteConsumer::ProcessOverloadCandidates(Sema &SemaRef,
|
|
|
|
unsigned CurrentArg,
|
2009-09-23 08:16:58 +08:00
|
|
|
OverloadCandidate *Candidates,
|
|
|
|
unsigned NumCandidates) {
|
|
|
|
for (unsigned I = 0; I != NumCandidates; ++I) {
|
2009-09-23 08:34:09 +08:00
|
|
|
if (CodeCompletionString *CCS
|
2011-02-02 03:23:04 +08:00
|
|
|
= Candidates[I].CreateSignatureString(CurrentArg, SemaRef,
|
|
|
|
Allocator)) {
|
2009-10-10 06:16:47 +08:00
|
|
|
OS << "OVERLOAD: " << CCS->getAsString() << "\n";
|
2009-09-23 08:16:58 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2009-11-07 08:00:49 +08:00
|
|
|
|
2012-03-17 14:39:06 +08:00
|
|
|
/// \brief Retrieve the effective availability of the given declaration.
|
|
|
|
static AvailabilityResult getDeclAvailability(Decl *D) {
|
|
|
|
AvailabilityResult AR = D->getAvailability();
|
|
|
|
if (isa<EnumConstantDecl>(D))
|
|
|
|
AR = std::max(AR, cast<Decl>(D->getDeclContext())->getAvailability());
|
|
|
|
return AR;
|
|
|
|
}
|
|
|
|
|
2011-10-06 15:27:49 +08:00
|
|
|
void CodeCompletionResult::computeCursorKindAndAvailability(bool Accessible) {
|
2010-08-14 06:48:40 +08:00
|
|
|
switch (Kind) {
|
2012-03-17 14:39:06 +08:00
|
|
|
case RK_Declaration: {
|
2010-08-24 07:00:57 +08:00
|
|
|
// Set the availability based on attributes.
|
2012-03-17 14:39:06 +08:00
|
|
|
switch (getDeclAvailability(Declaration)) {
|
Implement a new 'availability' attribute, that allows one to specify
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
2011-03-23 08:50:03 +08:00
|
|
|
case AR_Available:
|
|
|
|
case AR_NotYetIntroduced:
|
|
|
|
Availability = CXAvailability_Available;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case AR_Deprecated:
|
2010-08-24 07:00:57 +08:00
|
|
|
Availability = CXAvailability_Deprecated;
|
Implement a new 'availability' attribute, that allows one to specify
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
2011-03-23 08:50:03 +08:00
|
|
|
break;
|
2010-08-24 07:00:57 +08:00
|
|
|
|
Implement a new 'availability' attribute, that allows one to specify
which versions of an OS provide a certain facility. For example,
void foo()
__attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in
10.4, and completely obsoleted in 10.6. This attribute ties in with
the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that
we want to deploy back to Mac OS X 10.1). There are several concrete
behaviors that this attribute enables, as illustrated with the
function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo"
will result in a deprecation warning, as if we had placed
attribute((deprecated)) on it (but with a better diagnostic)
- If we choose a deployment target >= Mac OS X 10.6, uses of "foo"
will result in an "unavailable" warning (in C)/error (in C++), as
if we had placed attribute((unavailable)) on it
- If we choose a deployment target prior to 10.2, foo() is
weak-imported (if it is a kind of entity that can be weak
imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a
declaration, for different platforms; only the current platform
matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and
"macosx", since we already have -mxxxx-version-min flags for them and we
have experience there with macro tricks translating down to the
deprecated/unavailable/weak_import attributes. The end goal is to open
this up to other platforms, and even extension to other "platforms"
that are really libraries (say, through a #pragma clang
define_system), but that hasn't yet been designed and we may want to
shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and
unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
2011-03-23 08:50:03 +08:00
|
|
|
case AR_Unavailable:
|
|
|
|
Availability = CXAvailability_NotAvailable;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2010-09-04 07:30:36 +08:00
|
|
|
if (FunctionDecl *Function = dyn_cast<FunctionDecl>(Declaration))
|
|
|
|
if (Function->isDeleted())
|
2010-08-24 07:00:57 +08:00
|
|
|
Availability = CXAvailability_NotAvailable;
|
2010-09-04 07:30:36 +08:00
|
|
|
|
|
|
|
CursorKind = getCursorKindForDecl(Declaration);
|
2011-12-28 06:43:10 +08:00
|
|
|
if (CursorKind == CXCursor_UnexposedDecl) {
|
2012-01-02 05:23:57 +08:00
|
|
|
// FIXME: Forward declarations of Objective-C classes and protocols
|
|
|
|
// are not directly exposed, but we want code completion to treat them
|
|
|
|
// like a definition.
|
2011-12-28 06:43:10 +08:00
|
|
|
if (isa<ObjCInterfaceDecl>(Declaration))
|
|
|
|
CursorKind = CXCursor_ObjCInterfaceDecl;
|
2012-01-02 05:23:57 +08:00
|
|
|
else if (isa<ObjCProtocolDecl>(Declaration))
|
|
|
|
CursorKind = CXCursor_ObjCProtocolDecl;
|
2011-12-28 06:43:10 +08:00
|
|
|
else
|
|
|
|
CursorKind = CXCursor_NotImplemented;
|
|
|
|
}
|
2010-08-14 06:48:40 +08:00
|
|
|
break;
|
2012-03-17 14:39:06 +08:00
|
|
|
}
|
2010-08-14 06:48:40 +08:00
|
|
|
|
2010-08-25 14:19:51 +08:00
|
|
|
case RK_Macro:
|
2010-08-24 07:00:57 +08:00
|
|
|
Availability = CXAvailability_Available;
|
2010-08-14 06:48:40 +08:00
|
|
|
CursorKind = CXCursor_MacroDefinition;
|
|
|
|
break;
|
|
|
|
|
2010-08-25 14:19:51 +08:00
|
|
|
case RK_Keyword:
|
2010-08-24 07:00:57 +08:00
|
|
|
Availability = CXAvailability_Available;
|
2010-08-14 06:48:40 +08:00
|
|
|
CursorKind = CXCursor_NotImplemented;
|
|
|
|
break;
|
|
|
|
|
2010-08-25 14:19:51 +08:00
|
|
|
case RK_Pattern:
|
2010-08-14 06:48:40 +08:00
|
|
|
// Do nothing: Patterns can come with cursor kinds!
|
|
|
|
break;
|
2010-08-05 00:47:14 +08:00
|
|
|
}
|
2011-10-06 15:27:49 +08:00
|
|
|
|
|
|
|
if (!Accessible)
|
|
|
|
Availability = CXAvailability_NotAccessible;
|
2010-08-05 00:47:14 +08:00
|
|
|
}
|
2009-12-01 13:55:20 +08:00
|
|
|
|
2010-08-26 02:41:16 +08:00
|
|
|
/// \brief Retrieve the name that should be used to order a result.
|
|
|
|
///
|
|
|
|
/// If the name needs to be constructed as a string, that string will be
|
|
|
|
/// saved into Saved and the returned StringRef will refer to it.
|
2011-07-23 18:55:15 +08:00
|
|
|
static StringRef getOrderedName(const CodeCompletionResult &R,
|
2010-08-26 02:41:16 +08:00
|
|
|
std::string &Saved) {
|
|
|
|
switch (R.Kind) {
|
|
|
|
case CodeCompletionResult::RK_Keyword:
|
|
|
|
return R.Keyword;
|
|
|
|
|
|
|
|
case CodeCompletionResult::RK_Pattern:
|
|
|
|
return R.Pattern->getTypedText();
|
|
|
|
|
|
|
|
case CodeCompletionResult::RK_Macro:
|
|
|
|
return R.Macro->getName();
|
|
|
|
|
|
|
|
case CodeCompletionResult::RK_Declaration:
|
|
|
|
// Handle declarations below.
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
DeclarationName Name = R.Declaration->getDeclName();
|
|
|
|
|
|
|
|
// If the name is a simple identifier (by far the common case), or a
|
|
|
|
// zero-argument selector, just return a reference to that identifier.
|
|
|
|
if (IdentifierInfo *Id = Name.getAsIdentifierInfo())
|
|
|
|
return Id->getName();
|
|
|
|
if (Name.isObjCZeroArgSelector())
|
|
|
|
if (IdentifierInfo *Id
|
|
|
|
= Name.getObjCSelector().getIdentifierInfoForSlot(0))
|
|
|
|
return Id->getName();
|
|
|
|
|
|
|
|
Saved = Name.getAsString();
|
|
|
|
return Saved;
|
|
|
|
}
|
|
|
|
|
|
|
|
bool clang::operator<(const CodeCompletionResult &X,
|
|
|
|
const CodeCompletionResult &Y) {
|
|
|
|
std::string XSaved, YSaved;
|
2011-07-23 18:55:15 +08:00
|
|
|
StringRef XStr = getOrderedName(X, XSaved);
|
|
|
|
StringRef YStr = getOrderedName(Y, YSaved);
|
2010-08-26 02:41:16 +08:00
|
|
|
int cmp = XStr.compare_lower(YStr);
|
|
|
|
if (cmp)
|
|
|
|
return cmp < 0;
|
|
|
|
|
2010-08-26 21:48:20 +08:00
|
|
|
// If case-insensitive comparison fails, try case-sensitive comparison.
|
|
|
|
cmp = XStr.compare(YStr);
|
|
|
|
if (cmp)
|
|
|
|
return cmp < 0;
|
2010-08-26 02:41:16 +08:00
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|