llvm-svn: 93044

when the default case is winnowed down to be infeasible.  When all
cases were ruled out (and the analysis state for the default case
would be infeasible) we would still consider the default case
possible.  This fixes PR 5969.

llvm-svn: 93017

not just the viable ones.  This is reasonable because the most common use of
deleted functions is to exclude some implicit conversion during calls;  users
therefore will want to figure out why some other options were excluded.

Started sorting overload results.  Right now it just sorts by location in the
translation unit (after putting viable functions first), but we can do better than
that.

Changed bool OnlyViable parameter to PrintOverloadCandidates to an enum for better
self-documentation.

llvm-svn: 92990

targethook, which is no longer being used. This fixes PR5971.

llvm-svn: 92987

incorrect cast, causing compile error (fixes radar 7342867).

llvm-svn: 92986

llvm-svn: 92979

run-time initialization, and emit run-time initializers aggresively to avoid
ordering issues with deferred globals.

llvm-svn: 92976

suggestions follow recovery. Additionally, add a note to these
diagnostics which suggests a fix-it for changing the behavior to what
the user probably meant. Examples:

t.cpp:2:9: warning: & has lower precedence than ==; == will be evaluated first
      [-Wparentheses]
  if (i & j == k) {
        ^~~~~~~~
          (     )
t.cpp:2:9: note: place parentheses around the & expression to evaluate it first
  if (i & j == k) {
        ^
      (    )

t.cpp:14:9: warning: using the result of an assignment as a condition
without
      parentheses [-Wparentheses]
  if (i = f()) {
      ~~^~~~~
      (      )
t.cpp:14:9: note: use '==' to turn this assignment into an equality
comparison
  if (i = f()) {
        ^
        ==

llvm-svn: 92975

llvm-svn: 92973

implicitness without losing track of the (logical or actual) location
where "this" would occur in the source.

llvm-svn: 92958

_objc_method (part of radar 7490408).

llvm-svn: 92957

llvm-svn: 92952

as a type or scope token if the next token requires it.

This eliminates a lot of redundant lookups in C++, but there's room for
improvement;  a better solution would do a single lookup whose kind and
results would be passed through the parser.

llvm-svn: 92930

rewriting.

llvm-svn: 92925

llvm-svn: 92924

llvm-svn: 92923

llvm-svn: 92922

llvm-svn: 92917

llvm-svn: 92911

no viable overloads.  Use a different message when the class provides
no operator[] overloads at all; use it for operator(), too.

Partially addresses PR 5900.

llvm-svn: 92894

piece of the declaration.  The '@' and the 'end' are separate tokens,
and require two SourceLocations to accurately track.

This change was motivated because ObjCContainerDecl::getSourceRange()
would previously not return the entire range of the declaration (the
'end' would be left off).

llvm-svn: 92891

but this one is wrong.  Thanks to Tanya for noticing this.

llvm-svn: 92881

we look into a Scope that corresponds to a compound statement whose
scope was combined with the scope of the function that owns it. This
improves typo correction in many common cases.

llvm-svn: 92879

specifier that we corrected to.

llvm-svn: 92878

pointing to the declaration that we found that has that name (if it is
unique).

llvm-svn: 92877

corresponding @interface, provide a note showing which interface we're
referring to. This note has the fix-it hint on it.

Also, don't automatically apply fix-it hints for notes. They're meant
to express fix-its that would change semantics.

llvm-svn: 92870

ASTContext. Fixes <rdar://problem/7495428>.

llvm-svn: 92867

llvm-svn: 92866

llvm-svn: 92862

linkage of vtables. Before this, we were emitting RTTI names for
template instantiations with strong external linkage rather than with
weak ODR linkage.

llvm-svn: 92857

continuation classes and its original declaration
is imported from a protocol. This fixes radar 7509234.

llvm-svn: 92856

Fix marking of virtual members for nested classes whose first non-pure virtual function has a body inlined in the class

llvm-svn: 92855

llvm-svn: 92846

result for a nested class whose first non-pure virtual member function
has an inline body. Previously, we were checking for the key function
before we had seen the (delayed) inline body. 

llvm-svn: 92839

as parts of overload sets.  Also, refer to constructors as 'constructors'
rather than functions.

Adjust a lot of tests.

llvm-svn: 92832

llvm-svn: 92828

for -Wsign-compare and -Wconversion, and use that coordinated logic to drive
both diagnostics.  The new logic works more transparently with implicit
conversions, conditional operators, etc., as well as bringing -Wconversion's
ability to deal with pseudo-closed operations (e.g. arithmetic on shorts) to
-Wsign-compare.

Fixes PRs 5887, 5937, 5938, and 5939.

llvm-svn: 92823

Revert my available_externally vtables experiment. It's breaking the LLVM-with-Clang build with linker errors that I have yet to investigate.

llvm-svn: 92822

deterministic and work properly with templates. Once a class that
needs a vtable has been defined, we now do one if two things:

  - If the class has no key function, we place the class on a list of
    classes whose virtual functions will need to be "marked" at the
    end of the translation unit. The delay until the end of the
    translation unit is needed because we might see template
    specializations of these virtual functions.
  - If the class has a key function, we do nothing; when the key
    function is defined, the class will be placed on the
    aforementioned list.

At the end of the translation unit, we "mark" all of the virtual
functions of the classes on the list as used, possibly causing
template instantiation and other classes to be added to the
list. This gets LLVM's lib/Support/CommandLine.cpp compiling again.

llvm-svn: 92821

llvm-svn: 92819