sequences, where we would occasionally determine (incorrectly) that
one standard conversion sequence was a proper subset of another when,
in fact, they contained completely incomparable conversions. 

This change records the types in each step within a standard
conversion sequence, so that we can check the specific comparison
types to determine when one sequence is a proper subset of the
other. Fixes this testcase (thanks, Anders!), which was distilled from
PR6095 (also thanks to Anders).

llvm-svn: 94660

llvm-svn: 94565

This solution relies on an O(n) scan of redeclarations, which means it might
scale poorly in crazy cases with tons of redeclarations brought in by a ton
of distinct associated namespaces.  I believe that avoiding this
is not worth the common-case cost.

llvm-svn: 94530

about interaction between ADL and default arguments.  Shrug shoulders, commit.

llvm-svn: 94524

Fix a pretty bad bug where if a constructor (or conversion function) was marked as 'explicit', but then defined out-of-line, we would not treat it as being explicit.

llvm-svn: 94366

Use new initialization code when dealing with [dcl.init.aggr]p12. This fixes the bug where array elements and member initializers weren't copied correctly.

llvm-svn: 94340

llvm-svn: 94329

llvm-svn: 94327

Baby steps towards migrating the InitListChecker over to the new initialization code. Pass an InitializedEntity pointer through to most init checker functions. Right now, it's ignored everywhere except when initializing vectors in C++.

llvm-svn: 94325

incomplete type (or a pointer/reference to such).

The causes of this problem are different enough to justify a different "design"
for the diagnostic.  Most notably, it doesn't give an operand index:
it's usually pretty obvious which operand is the problem, it adds a lot of
clutter to mention it, and the fix is usually in a different part of the file
anyway.

This is yet another diagnostic that should really have an analogue in the
non-overloaded case --- which should be much easier to write because of
the weaker space constraints.

llvm-svn: 94303

Fix the EntityKind order so that all entity kinds that can be copied (using copy constructors) come first. Also, fix a bug where EK_New was left out of the err_init_conversion_failed diagnostic (It is now reported as 'new value'). Please review Doug :)

llvm-svn: 94289

llvm-svn: 94268

lookup. Fixes radar 7562438.

llvm-svn: 94191

No need to canonicalize the type and use dyn_cast. Also, correctly diagnose trying to override a function returning an lvalue reference with a function overriding an rvalue reference.

llvm-svn: 94183

when checking for covariance. Added some fun test cases, fixes PR6110.

This felt obvious enough to just commit. ;] Let me know if anything needs
tweaking.

llvm-svn: 94173

dead array references.

llvm-svn: 94115

llvm-svn: 94106

llvm-svn: 94093

unary operators.

llvm-svn: 94084

CallExprs as those edges help cause a n^2 explosion in the number of
destructor calls.  Other consumers, such as static analysis, that
would like to have more a more complete CFG can select the inclusion
of those edges as CFG build time.

This also fixes up the two compilation users of CFGs to be tolerant of
having or not having those edges.  All catch code is assumed be to
live if we didn't generate the exceptional edges for CallExprs.

llvm-svn: 94074

ForRedeclaration flag so that we don't look into base classes. 
Fixes PR6061.

llvm-svn: 93862

llvm-svn: 93644

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

llvm-svn: 93420

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

llvm-svn: 93395

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

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

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: 93216

sequence.  Lots of small relevant changes.  Fixes some serious problems with
ambiguous conversions;  also possibly improves associated diagnostics.

llvm-svn: 93214

llvm-svn: 93190

for all visible conversion functions.

llvm-svn: 93173

llvm-svn: 93150

llvm-svn: 93015

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

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

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

llvm-svn: 92858