Commit Graph

9 Commits

Author SHA1 Message Date
Kaelyn Uhrain 9ea8f7e6c5 Improve the error message when a function overload candidate is rejected
because it expects a reference and receives a non-l-value.

For example, given:

  int foo(int &);
  template<int x> void b() { foo(x); }

clang will now print "expects an l-value for 1st argument" instead of
"no known conversion from 'int' to 'int &' for 1st argument". The change
in wording (and associated code to detect the case) was prompted by
comment  in PR3104, and should be the last bit of work needed for the
bug.

llvm-svn: 158691
2012-06-19 00:37:47 +00:00
Douglas Gregor c7a3107baf When performing a user-defined conversion via a constructor, be sure
to check whether the constructor is accessible. Fixes
<rdar://problem/10202900>.

llvm-svn: 141588
2011-10-10 22:41:00 +00:00
Douglas Gregor 5ab1165531 Improve our handling of user-defined conversions as part of overload
resolution. There are two sources of problems involving user-defined
conversions that this change eliminates, along with providing simpler
interfaces for checking implicit conversions:

  - It eliminates a case of infinite recursion found in Boost.

  - It eliminates the search for the constructor needed to copy a temporary
    generated by an implicit conversion from overload
    resolution. Overload resolution assumes that, if it gets a value
    of the parameter's class type (or a derived class thereof), there
    is a way to copy if... even if there isn't. We now model this
    properly.

llvm-svn: 101680
2010-04-17 22:01:05 +00:00
Daniel Dunbar 8fbe78f6fc Update tests to use %clang_cc1 instead of 'clang-cc' or 'clang -cc1'.
- This is designed to make it obvious that %clang_cc1 is a "test variable"
   which is substituted. It is '%clang_cc1' instead of '%clang -cc1' because it
   can be useful to redefine what gets run as 'clang -cc1' (for example, to set
   a default target).

llvm-svn: 91446
2009-12-15 20:14:24 +00:00
Daniel Dunbar a45cf5b6b0 Rename clang to clang-cc.
Tests and drivers updated, still need to shuffle dirs.

llvm-svn: 67602
2009-03-24 02:24:46 +00:00
Douglas Gregor bb2e688396 Steve set me straight on this one. GCC was right, EDG was wrong: the
direct-initialization following a user-defined conversion can select
any constructor; it just can't employ any user-defined
conversions. So we ban those conversions and classify the constructor
call based on the relationship between the "from" and "to" types in
the conversion.

llvm-svn: 63554
2009-02-02 22:11:10 +00:00
Douglas Gregor 576e98cc1e Improve our handling of the second step in a user-defined conversion
sequence. Previously, we weren't permitting the second step to call
copy constructors, which left user-defined conversion sequences
surprisingly broken.

Now, we perform overload resolution among all of the constructors, but
only accept the result if it makes the conversion a standard
conversion. Note that this behavior is different from both GCC and EDG
(which don't agree with each other, either); I've submitted a core
issue on the matter.

llvm-svn: 63450
2009-01-30 23:27:23 +00:00
Douglas Gregor f52cdd0124 Allow user-defined conversions during reference binding
llvm-svn: 58988
2008-11-10 16:14:15 +00:00
Douglas Gregor a1f013e8ed Initial, partially-baked support for implicit user-defined conversions by conversion functions
llvm-svn: 58870
2008-11-07 22:36:19 +00:00