ignore it during overload resolution when initializing
X from a value of type cv X.
Previously, our rule here only ignored specializations
of constructor templates. That's probably because the
standard says that constructors are outright ill-formed
if their first parameter is literally X and they're
callable with one argument. However, Clang only
enforces that prohibition against non-implicit
instantiations; I'm not sure why, but it seems to be
deliberate. Given that, the most sensible thing to
do is to just ignore the "illegal" constructor
regardless of where it came from.
Also, stop ignoring such constructors silently:
print a note explaining why they're being ignored.
Fixes <rdar://19199836>.
llvm-svn: 224205
We don't yet support pointer-to-member template arguments that have undergone
pointer-to-member conversions, mostly because we don't have a mangling for them yet.
llvm-svn: 222807
Summary:
We have this error from a while (Wed Jun 15 18:02:42 2011
r133103)
Reviewers: rsmith
Reviewed By: rsmith
Differential Revision: http://reviews.llvm.org/D6296
llvm-svn: 222169
As PR20495 demonstrates, Clang currenlty infers the CUDA target (host/device,
etc) for implicit members (constructors, etc.) incorrectly. This causes errors
and even assertions in Clang when compiling code (assertions in C++11 mode where
implicit move constructors are added into the mix).
Fix the problem by inferring the target from the methods the implicit member
should call (depending on its base classes and fields).
llvm-svn: 218624
that function, and apart from being slow, this is unnecessary: ADL can trigger
instantiations that are not permitted here. The standard isn't *completely*
clear here, but this seems like the intent, and in any case this approach is
permitted by [temp.inst]p7.
llvm-svn: 218330
global pool in the course of method selection for
a messaging expression, select one with the most general
return type of 'id'. This is to remove type-mismatch
warning (which is useless) as result of random selection of
method with more restrictive return type. rdar://18095772
llvm-svn: 216560
Changes diagnostic options, language standard options, diagnostic identifiers, diagnostic wording to use c++14 instead of c++1y. It also modifies related test cases to use the updated diagnostic wording.
llvm-svn: 215982
MSVC doesn't decide what the inheritance model for a returned member
pointer *until* a call expression returns it.
This fixes PR20017.
llvm-svn: 215164
Summary:
If during constructing a standard conversion sequence, we resolve an
overload, we need to adjust the from type in the SCS according to the
resolved operator.
I found this bug when debugging PR20218. This doesn't seem to be
observable, so there is no good way of testing it.
Reviewers: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4402
llvm-svn: 213680
array prvalue), treat that as a direct binding. Only the class prvalue case
needs to be excluded here; the rest are extensions anyway, so we can treat them
as we would in C++11.
llvm-svn: 212978
a function pointer is neither better nor worse than binding a function lvalue
to a function rvalue reference. Don't get confused and think that both bindings
are binding to a function lvalue (which would make the lvalue form win); the
const reference is binding to an rvalue.
The "real" bug in PR20218 is still present: we're getting the wrong answer from
template argument deduction, and that's what leads us to this weird overload
set.
llvm-svn: 212916
Testcase coming out of creduce will land in a separate commit shortly.
Also, it appears that this callback is used even in a SFINAE context where the results are never displayed.
llvm-svn: 208062
order by the number of missing or extra parameters. This is useful if
there are more than a few overload candidates with arity mismatches,
particularly in the presence of -fshow-overloads=best.
llvm-svn: 207796
obviously won't work. Specifically, don't suggest methods (static or
not) from unrelated classes when the expression is a method call
through a specific object.
llvm-svn: 205653
When a lax conversion featured a vector and a non-vector, we were
only requiring the non-vector to be a scalar type, but really it
needs to be a real type (i.e. integral or real floating); it is
not reasonable to allow a pointer, member pointer, or complex
type here.
r198474 required lax conversions to match in "data size", i.e.
element size * element count, forbidding matches that happen
only because a vector is rounded up to the nearest power of two
in size. Unfortunately, the erroneous logic was repeated in
several different places; unify them to use the new condition,
so that it triggers for arbitrary conversions and not just
those performed as part of binary operator checking.
rdar://15931426
llvm-svn: 200810
