| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
_Foo) from code-completion results when they come from a system
header.
llvm-svn: 108338
|
|
|
|
|
|
|
| |
completions. Plus, tweak a few completion patterns to better reflect
the language grammar.
llvm-svn: 104905
|
|
|
|
|
|
| |
statements }) in the code-completion results if explicitly requested.
llvm-svn: 104637
|
|
|
|
|
|
|
|
| |
a missing */ since we truncated the file.
This fixes rdar://7948776
llvm-svn: 103913
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 100557
|
|
|
|
|
|
|
| |
statement or for ordinary names. This means that we won't show macros
when completing, e.g., member expressions such as "p->".
llvm-svn: 100555
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 94076
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 91702
|
|
|
|
|
|
|
|
|
| |
- 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
|
|
|
|
| |
llvm-svn: 91303
|
|
|
|
|
|
| |
informative chunk.
llvm-svn: 91139
|
|
|
|
| |
llvm-svn: 91138
|
|
|
|
| |
llvm-svn: 91137
|
|
|
|
|
|
|
|
|
| |
specializations and class template partial specializations (they're
never named directly). Also, member access expressions only refer to
value declarations (fields, functions, enumerators, etc.) and
Objective-C property declarations; filter out everything else.
llvm-svn: 91133
|
|
|
|
|
|
| |
completion results
llvm-svn: 91125
|
|
|
|
|
|
|
|
|
| |
declaration by providing patterns for "getter = <method>" and "setter
= <method>". As part of this, invented a new "pattern" result kind
that is merely a semantic string. The "pattern" result kind should
help with other kinds of code templates.
llvm-svn: 89277
|
|
|
|
|
|
|
|
|
| |
code to find and add Objective-C methods (starting at an
ObjCContainerDecl) into a single, static function. Also, make sure
that we search into the implementations of classes and categories to
find even more methods.
llvm-svn: 89163
|
|
|
|
| |
llvm-svn: 86432
|
|
|
|
|
|
| |
- 'for i in $(find . -type f); do sed -e 's#\(RUN:.*[^ ]\) *&& *$#\1#g' $i | FileUpdate $i; done', for the curious.
llvm-svn: 86430
|
|
|
|
|
|
| |
Still a work in progress...
llvm-svn: 86323
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Introduce more code-completion string "chunk" kinds that describe
symbols, the actual text that the user is expected to type, etc.
- Make the generation of macro results optional, since it can be
slow
- Make code-completion accessible through the C API, marshalling the
code-completion results through a temporary file (ick) to maintain
process separation.
The last doesn't have tests yet.
llvm-svn: 86306
|
|
|
|
| |
llvm-svn: 85594
|
|
|
|
|
|
|
|
| |
(compare was system dependent). Worked on Linux, failed on Mac OS (which caused the recently added testcase to fail on Linux).
- Sort results in testcase.
llvm-svn: 83597
|
|
|
|
| |
llvm-svn: 83579
|
|
|
|
| |
llvm-svn: 82962
|
|
|
|
| |
llvm-svn: 82726
|
|
|
|
|
|
|
|
| |
lookup in a member access expression always start a
nested-name-specifier. Additionally, rank names that start
nested-name-specifiers after other names.
llvm-svn: 82663
|
|
|
|
|
|
|
|
| |
that there is one more argument (the one following the comma) and make
the candidate non-viable if the function cannot accept any argument in
that position.
llvm-svn: 82625
|
|
|
|
|
|
|
| |
signature of the function with the current parameter highlighted as a
placeholder.
llvm-svn: 82593
|
|
|
|
|
|
|
|
| |
results for other, textual completion. For call completion, we now
produce enough information to show the function call argument that we
are currently on.
llvm-svn: 82592
|
|
|
|
|
|
|
| |
the start of a nested-name-specifier, add the "::" after the
nested-name-specifier to the code-completion string.
llvm-svn: 82587
|
|
|
|
|
|
|
|
|
|
|
| |
members found in base classes have the same ranking as members found
in derived classes. However, we will introduce an informative note for
members found in base classes, showing (as a nested-name-specifier)
the qualification to name the base class, to make it clear which
members are from bases.
llvm-svn: 82586
|
|
|
|
| |
llvm-svn: 82577
|
|
|
|
|
|
|
|
|
|
|
| |
-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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
opening parentheses and after each comma. We gather the set of visible
overloaded functions, perform "partial" overloading based on the set
of arguments that we have thus far, and return the still-viable
results sorted by the likelihood that they will be the best candidate.
Most of the changes in this patch are a refactoring of the overloading
routines for a function call, since we needed to separate out the
notion of building an overload set (common to code-completion and
normal semantic analysis) and then what to do with that overload
set. As part of this change, I've pushed explicit template arguments
into a few more subroutines.
There is still much more work to do in this area. Function templates
won't be handled well (unless we happen to deduce all of the template
arguments before we hit the completion point), nor will overloaded
function-call operators or calls to member functions.
llvm-svn: 82549
|
|
|
|
|
|
| |
expression, or statement
llvm-svn: 82481
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a nested-name-specifier that describes how to refer to that name. For
example, given:
struct Base { int member; };
struct Derived : Base { int member; };
the code-completion result for a member access into "Derived" will
provide both "member" to refer to Derived::member (no qualification needed) and
"Base::member" to refer to Base::member (qualification included).
llvm-svn: 82476
|
|
|
|
|
|
|
|
|
| |
enumerators when either the user intentionally wrote a qualified name
(in which case we just use that nested-name-specifier to match
the user's code) or when this is the first "case" statement and we
need a qualified name to refer to an enumerator in a different scope.
llvm-svn: 82474
|
|
|
|
|
|
| |
of enumeration type, providing the various unused enumerators as options.
llvm-svn: 82467
|
|
|
|
|
|
|
| |
"->", or "::" if we will be looking into a dependent context. It's not
wrong to use the "template" keyword, but it's to needed, either.
llvm-svn: 82307
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template smarter, by taking into account which function template
parameters are deducible from the call arguments. For example,
template<typename RandomAccessIterator>
void sort(RandomAccessIterator first, RandomAccessIterator last);
will have a code-completion string like
sort({RandomAccessIterator first}, {RandomAccessIterator last})
since the template argument for its template parameter is
deducible. On the other hand,
template<class X, class Y>
X* dyn_cast(Y *Val);
will have a code-completion string like
dyn_cast<{class X}>({Y *Val})
since the template type parameter X is not deducible from the function
call.
llvm-svn: 82306
|
|
|
|
|
|
| |
angle brackets < > along with placeholder template arguments.
llvm-svn: 82304
|
|
|
|
|
|
|
| |
results of code completion, e.g., by providing function call syntax
with placeholders for each of the parameters.
llvm-svn: 82293
|
|
|
|
|
|
| |
operators, type specifiers, type names, and nested-name-specifiers.
llvm-svn: 82264
|
|
|
|
|
|
|
|
|
|
| |
- after "using", show anything that can be a nested-name-specifier.
- after "using namespace", show any visible namespaces or namespace aliases
- after "namespace", show any namespace definitions in the current scope
- after "namespace identifier = ", show any visible namespaces or
namespace aliases
llvm-svn: 82251
|