| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
__attribute__((enable_if)), both in the condition expression and at the call site. Fixes PR20988!
llvm-svn: 224320
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
| |
arguments).
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
|
|
|
|
|
|
| |
pair<iterator, bool> as per the C++ standard's associative container concept.
llvm-svn: 222335
|
|
|
|
| |
llvm-svn: 222315
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
static functions. Make a bunch of file-local functions static. Remove one
unused static function revealed by this.
llvm-svn: 221745
|
|
|
|
|
|
| |
TypoCorrectionConsumer can keep the callback around as long as needed.
llvm-svn: 220693
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
http://reviews.llvm.org/D5298
llvm-svn: 218482
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
and mentioning the type. This works now that we have a conversion from ArrayRef<T*> to ArrayRef<const T*>.
llvm-svn: 216710
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
just letting them be implicitly created.
llvm-svn: 216528
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
// rdar://16808765
llvm-svn: 215581
|
|
|
|
|
|
|
| |
expression to the best method found in global method pools.
This is wip. // rdar://16808765
llvm-svn: 215577
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 213013
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 211988
|
|
|
|
| |
llvm-svn: 211987
|
|
|
|
| |
llvm-svn: 209812
|
|
|
|
|
|
| |
takeAs to getAs.
llvm-svn: 209800
|
|
|
|
| |
llvm-svn: 209613
|
|
|
|
|
|
| |
comparison check to use this instead of calling Type::getCanonicalTypeInternal
llvm-svn: 209378
|
|
|
|
|
|
| |
classes is a template argument.
llvm-svn: 209190
|
|
|
|
|
|
| |
bug was obvious from inspection, figuring out a way to test it was... less so.
llvm-svn: 209060
|
|
|
|
| |
llvm-svn: 209055
|
|
|
|
|
|
| |
conversion operators (the comparison could claim that two conversion operators are both better than each other). Actually implement DR495, rather than passing its test by chance because the declarations happened to be in the "lucky" order.
llvm-svn: 209054
|
|
|
|
|
|
|
| |
Required pulling LambdaExpr::Capture into its own header.
No functionality change.
llvm-svn: 208470
|
|
|
|
|
|
| |
have arity mismatches.
llvm-svn: 208146
|
|
|
|
|
|
|
|
|
|
| |
Patch by Kaelyn Takata.
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
|
|
|
|
| |
llvm-svn: 207896
|
|
|
|
|
|
| |
Code review feedback from Reid Kleckner on r207806.
llvm-svn: 207811
|
|
|
|
| |
llvm-svn: 207806
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
| |
when building the candidate set, rather than trying to contort name lookup into
handling this.
llvm-svn: 206436
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
compareConversionFunctions() on incorrect code.
I'm looking into getting a reduced test case, but it's not
immediately available.
Fixes <rdar://problem/16344806>
llvm-svn: 205285
|
|
|
|
|
|
| |
class.
llvm-svn: 203640
|
|
|
|
|
|
| |
Replace OwningArrayPtr with std::unique_ptr<T[]>.
llvm-svn: 203388
|
|
|
|
|
|
| |
iterator_range fields(). Updating all of the usages of the iterators with range-based for loops.
llvm-svn: 203355
|
|
|
|
|
|
|
| |
won't work (i.e. when not doing a member lookup and not in a method from
the same class or a descendant class).
llvm-svn: 202520
|
|
|
|
| |
llvm-svn: 202467
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
and revert its behavior for C++.
llvm-svn: 200622
|
|
|
|
|
|
|
|
|
|
| |
casts, which are used
by some projects in their null macro.
rdar://15925483
llvm-svn: 200521
|