Thread a source location into the template-argument deduction routines. There
may be some other places that could take advantage of this new information,
but I haven't really looked yet.

llvm-svn:

Thread a source location into the template-argument deduction routines. There
may be some other places that could take advantage of this new information,
but I haven't really looked yet.

llvm-svn: 95600

show more ...

Implement the lvalue-to-rvalue conversion where needed. The
lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class
type to rvalue expressions of the unqualified variant of that
type. For

Implement the lvalue-to-rvalue conversion where needed. The
lvalue-to-rvalue conversion adjusts lvalues of qualified, non-class
type to rvalue expressions of the unqualified variant of that
type. For example, given:

const int i;
(void)(i + 17);

the lvalue-to-rvalue conversion for the subexpression "i" will turn it
from an lvalue expression (a DeclRefExpr) with type 'const int' into
an rvalue expression with type 'int'. Both C and C++ mandate this
conversion, and somehow we've slid through without implementing it.

We now have both DefaultFunctionArrayConversion and
DefaultFunctionArrayLvalueConversion, and which gets used depends on
whether we do the lvalue-to-rvalue conversion or not. Generally, we do
the lvalue-to-rvalue conversion, but there are a few notable
exceptions:
- the left-hand side of a '.' operator
- the left-hand side of an assignment
- a C++ throw expression
- a subscript expression that's subscripting a vector

Making this change exposed two issues with blocks:
- we were deducing const-qualified return types of non-class type
from a block return, which doesn't fit well
- we weren't always setting the known return type of a block when it
was provided with the ^return-type syntax

Fixes the current Clang-on-Clang compile failure and PR6076.

llvm-svn: 95167

show more ...

Pass access specifiers around in overload resolution.

llvm-svn: 94485

Teach code-completion to deal with calls to functions without prototypes.

llvm-svn: 94076

Switch a few callers of MaybeAddResult over to AddResult, when the
declarations we're adding do not need any name-hiding checks.

llvm-svn: 93431

Switch code-completion's ivar lookup over to LookupVisibleDecls,
eliminating yet one more ResultBuilder::MaybeAddResult caller.

llvm-svn: 93430

Start migrating code-completion results from
ResultBuilder::MaybeAddResult over to ResultBuilder::AddResult.

llvm-svn: 93429

Switch the remaining code completions over to LookupVisibleDecls,
after adding the ability to determine whether our lookup is a
base-class lookup. Eliminate CollectMemberLookupResults, since it is
no

Switch the remaining code completions over to LookupVisibleDecls,
after adding the ability to determine whether our lookup is a
base-class lookup. Eliminate CollectMemberLookupResults, since it is
no longer used (yay).

llvm-svn: 93428

show more ...

Move code completion for qualified name lookup (foo::) to
LookupVisibleDecls. Also, a function does not hide another function.

llvm-svn: 93421

Eliminate the code-completion-specifier CollectLookupResults in favor
of the more general LookupVisibleDecls.

llvm-svn: 93419

Simplify the code-completion logic for nested-name-specifiers: rather
than traversing visible declarations twice, only perform one traversal
and recognize nested-name-specifiers as special.

llvm-svn

Simplify the code-completion logic for nested-name-specifiers: rather
than traversing visible declarations twice, only perform one traversal
and recognize nested-name-specifiers as special.

llvm-svn: 93418

show more ...

When providing completions for a member access expression in C++,
provided nested-name-specifier results for base classes (only), rather
than everything that could possibly be a nested-name-specifier

When providing completions for a member access expression in C++,
provided nested-name-specifier results for base classes (only), rather
than everything that could possibly be a nested-name-specifier.

llvm-svn: 93398

show more ...

Switch code-completion for ordinary names over to the new(ish)
LookupVisibleDecls, unifying the name lookup mechanisms used by code
completion and typo correction. Aside from the software-engineering

Switch code-completion for ordinary names over to the new(ish)
LookupVisibleDecls, unifying the name lookup mechanisms used by code
completion and typo correction. Aside from the software-engineering
improvements, this makes code-completion see through using directives
and see ivars when performing unqualified name lookup in an
Objective-C instance method.

llvm-svn: 93397

show more ...

More refactoring of ResultBuilder::MaybeAddResult. No intended
functionality change.

llvm-svn: 93386

Refactor the "is this declaration interesting" logic in
code-completion's ResultBuilder::MaybeAddResult for later reuse.

llvm-svn: 93379

Banish the notion of a "rank" for code-completion results, since we
are no longer using it for anything. No intended functionality change.

llvm-svn: 93376

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 a

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

show more ...

Code-completion for @public, @protected, @private, @package.

llvm-svn: 93361

Whenever completing ordinary names for an Objective-C source, also
provide completions for @ keywords. Previously, we only provided
@-completions after an @ was actually typed, which is useful but
pr

Whenever completing ordinary names for an Objective-C source, also
provide completions for @ keywords. Previously, we only provided
@-completions after an @ was actually typed, which is useful but
probably not the common case.

Also, make sure a few Objective-C 2.0 completions only show up when
Objective-C 2.0 support is enabled (the default).

llvm-svn: 93354

show more ...

Use horizontal-space markers in code-completion results rather than
embedding single space characters. <rdar://problem/7485503>

llvm-svn: 93231

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,

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

show more ...

remove extraneous #include

llvm-svn: 92310

Typo correction for type names when they appear in declarations, e.g., given

tring str2;

we produce the following diagnostic + fix-it:

typo.cpp:15:1: error: unknown type name 'tring'; did you me

Typo correction for type names when they appear in declarations, e.g., given

tring str2;

we produce the following diagnostic + fix-it:

typo.cpp:15:1: error: unknown type name 'tring'; did you mean 'string'?
tring str2;
^~~~~
string


To make this really useful, we'll need to introduce typo correction in
many more places (wherever we do name lookup), and implement
declaration-vs-expression heuristics that cope with typos
better. However, for now this will handle the simple cases where we
already get good "unknown type name" diagnostics.

The LookupVisibleDecls functions are intended to be used by code
completion as well as typo correction; that refactoring will happen
later.

llvm-svn: 92308

show more ...

Remove some dead variables clang-analyzer found.

llvm-svn: 92162

Objective-C methods can be variadic, too. Who knew.

llvm-svn: 91951