| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 82543
|
|
|
|
|
|
| |
breaking some projects, but I don't have a test case yet.
llvm-svn: 82539
|
|
|
|
|
|
| |
- Switching all of them out-of-my-current-scope-of-interest, sorry.
llvm-svn: 82515
|
|
|
|
|
|
|
|
|
|
|
| |
Several of the existing methods were identical to their respective
specializations, and so have been removed entirely. Several more 'leaf'
optimizations were introduced.
The getAsFoo() methods which imposed extra conditions, like
getAsObjCInterfacePointerType(), have been left in place.
llvm-svn: 82501
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
real work is performed within Sema. Addresses Chris's comments, but
still retains the heavyweight list-of-multimaps data structure.
llvm-svn: 82459
|
|
|
|
|
|
|
| |
"->", 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
|
|
|
|
|
|
| |
during code completion
llvm-svn: 82234
|
|
|
|
| |
llvm-svn: 82233
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
look into the current scope for anything that could start a
nested-names-specifier. These results are ranked worse than any of the
results actually found in the lexical scope.
Perform a little more pruning of the result set, eliminating
constructors, __va_list_tag, and any duplication of declarations in
the result set. For the latter, implemented
NamespaceDecl::getCanonicalDecl.
llvm-svn: 82231
|
|
|
|
|
|
|
| |
results when there is some way to refer to them in the language, such
as with a qualified name in C++.
llvm-svn: 82223
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
will provide the names of various enumerations currently
visible. Introduced filtering of code-completion results when we build
the result set, so that we can identify just the kinds of declarations
we want.
This implementation is incomplete for C++, since we don't consider
that the token after the tag keyword could start a
nested-name-specifier.
llvm-svn: 82222
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
complain about specializations of member functions that are not
definitions. Fixes PR4995.
llvm-svn: 82159
|
|
|
|
|
|
|
|
| |
- Doug, please check.
- PR4940.
llvm-svn: 82129
|
|
|
|
| |
llvm-svn: 82128
|
|
|
|
|
|
| |
function type argument types.
llvm-svn: 82093
|
|
|
|
|
|
| |
same.
llvm-svn: 82088
|
|
|
|
| |
llvm-svn: 82072
|
|
|
|
|
|
|
|
|
|
| |
when we are not instantiating the corresponding "current
instantiation." This happens, e.g., when we are instantiating a
declaration reference that refers into the "current instantiation" but
occurs in a default function argument. The libstdc++ vector default
constructor now instantiates properly.
llvm-svn: 82069
|
|
|
|
| |
llvm-svn: 81960
|
|
|
|
|
|
|
|
|
|
|
|
| |
give them the appropriate exception specifications. This,
unfortunately, requires us to maintain and/or implicitly generate
handles to namespace "std" and the class "std::bad_alloc". However,
every other approach I've come up with was more hackish, and this
standard requirement itself is quite the hack.
Fixes PR4829.
llvm-svn: 81939
|
|
|
|
|
|
|
|
| |
to pointer function for delete expression. 2)
Treat type conversion function and its 'const' version
as identical in building the visible conversion list.
llvm-svn: 81930
|
|
|
|
| |
llvm-svn: 81917
|
|
|
|
|
|
|
|
|
|
| |
point at the template and print out its template arguments, e.g.,
ambiguous-ovl-print.cpp:5:8: note: candidate function template specialization
[with T = int]
void f(T*, long);
llvm-svn: 81907
|
|
|
|
|
|
| |
ambiguity in type conversion function selection.
llvm-svn: 81898
|
|
|
|
|
|
| |
existing bug
llvm-svn: 81885
|
|
|
|
|
|
|
| |
function for delete of a class expression and issue
good diagnostic when result is ambiguous.
llvm-svn: 81870
|
|
|
|
|
|
|
| |
ordering, along with another test case for partial ordering of partial
specializations.
llvm-svn: 81869
|
|
|
|
|
|
| |
(C++ [temp.class.order]).
llvm-svn: 81866
|
|
|
|
| |
llvm-svn: 81863
|
|
|
|
|
|
| |
object to that base class.
llvm-svn: 81852
|
|
|
|
|
|
| |
standard conversion sequence. This lets us remove a workaround in SemaCompleteConstructorCall.
llvm-svn: 81847
|
|
|
|
| |
llvm-svn: 81844
|
|
|
|
| |
llvm-svn: 81842
|
|
|
|
| |
llvm-svn: 81841
|
|
|
|
| |
llvm-svn: 81839
|
|
|
|
| |
llvm-svn: 81837
|
|
|
|
|
|
| |
a type convesion function results in ambiguity.
llvm-svn: 81812
|
|
|
|
| |
llvm-svn: 81808
|
|
|
|
|
|
| |
conversion function.
llvm-svn: 81807
|
|
|
|
|
|
| |
an overloaded function (template).
llvm-svn: 81804
|