ResultBuilder::MaybeAddResult over to ResultBuilder::AddResult.

llvm-svn: 93429

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

LookupVisibleDecls. Also, a function does not hide another function.

llvm-svn: 93421

for special diagnostics.  Unfortunately, the non-overload diagnostics are not
this good.

llvm-svn: 93420

of the more general LookupVisibleDecls.

llvm-svn: 93419

than traversing visible declarations twice, only perform one traversal
and recognize nested-name-specifiers as special.

llvm-svn: 93418

Thanks Ted.

llvm-svn: 93413

need an error term for the CFG.  I suspect we'll always have to cope
with getCFG returning 0, though, I'd love to see even that possibility
removed.

llvm-svn: 93411

provided nested-name-specifier results for base classes (only), rather
than everything that could possibly be a nested-name-specifier.

llvm-svn: 93398

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

about 'object argument' vs. 'nth argument'.

llvm-svn: 93395

functionality change.

llvm-svn: 93386

code-completion's ResultBuilder::MaybeAddResult for later reuse.

llvm-svn: 93379

llvm-svn: 93378

are no longer using it for anything. No intended functionality change.

llvm-svn: 93376

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

to be considering user-defined conversions in the first place.

Doug, please review;  I'm not sure what we should be doing if we see a real
ambiguity in selecting a copy constructor when otherwise suppressing
user-defined conversions.

Fixes PR6014.

llvm-svn: 93365

llvm-svn: 93362

llvm-svn: 93361

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

Patch by Enea Zaffanella.

llvm-svn: 93344

that name constructors, the endless joys of out-of-line constructor
definitions, and various other corner cases that the previous hack
never imagined. Fixes PR5688 and tightens up semantic analysis for
constructor names.

Additionally, fixed a problem where we wouldn't properly enter the
declarator scope of a parenthesized declarator. We were entering the
scope, then leaving it when we saw the ")"; now, we re-enter the
declarator scope before parsing the parameter list.

Note that we are forced to perform some tentative parsing within a
class (call it C) to tell the difference between

  C(int); // constructor

and

  C (f)(int); // member function

which is rather unfortunate. And, although it isn't necessary for
correctness, we use the same tentative-parsing mechanism for
out-of-line constructors to improve diagnostics in icky cases like:

  C::C C::f(int); // error: C::C refers to the constructor name, but
                  // we complain nicely and recover by treating it as
                  // a type.

llvm-svn: 93322

information to feed diagnostics instead of regenerating it.  Much room for
improvement here, but fixes some unfortunate problems reporting on method calls.

llvm-svn: 93316

This now rejects literal operators that don't meet the requirements.
Templates are not yet checked for.

llvm-svn: 93315

llvm-svn: 93287

why the candidate is non-viable.  There's a lot we can do to improve this, but
it's a good start.  Further improvements should probably be integrated with the
bad-initialization reporting routines.

llvm-svn: 93277

redefined. There's a FIXME with an apology about why we don't try to
do better here. Fixes <rdar://problem/7513023>.

llvm-svn: 93274

ivar name lookup. Fixes pr5986.

llvm-svn: 93271

unevaluated contexts, because they only matter for code that will
actually be evaluated at runtime.

As part of this, I had to extend PartialDiagnostic to support fix-it
hints.

llvm-svn: 93266

not in an evaluated context.  This removes some bogus warnings.

llvm-svn: 93258

name a template, when they occur in a base-specifier. This is one of
the (few) places where we know for sure that an identifier followed by
a '<' must be a template name, so we can diagnose and recover well:

test/SemaTemplate/dependent-base-classes.cpp:9:16: error: missing
'template'
      keyword prior to dependent template name 'T::apply'
struct X1 : T::apply<U> { }; // expected-error{{missing 'template' ...
               ^
               template 
test/SemaTemplate/dependent-base-classes.cpp:12:13: error: unknown
template name
      'vector'
struct X2 : vector<T> { }; // expected-error{{unknown template name
'vector'}}
            ^
2 diagnostics generated.

llvm-svn: 93257

llvm-svn: 93256

llvm-svn: 93255

correctly look through arrays to see cv-qualifiers. Also enhances the routine
for doing this to preserve more type sugaring for diagnostics.

llvm-svn: 93252

context, do not attempt typo correction. This harms performance (as
Abramo noted) and can cause some amusing errors, as in this new
testcase.

llvm-svn: 93240

I said to myself, self, why don't you go add a couple of parameters to a method
and then fail to use them, and I thought that sounded like a pretty good idea,
so I did it.

llvm-svn: 93233

embedding single space characters. <rdar://problem/7485503>

llvm-svn: 93231

fidelity with which we note them as functions/constructors and templates
thereof.  Also will be helpful when reporting bad conversions (next).

llvm-svn: 93224

llvm-svn: 93217

llvm-svn: 93215