| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A return type is the declared or deduced part of the function type specified in
the declaration.
A result type is the (potentially adjusted) type of the value of an expression
that calls the function.
Rule of thumb:
* Declarations have return types and parameters.
* Expressions have result types and arguments.
llvm-svn: 200082
|
|
|
|
|
|
|
| |
This is the second msan failure where UserDefinedConversion does not initialize
its `Before` member as identity conversion.
llvm-svn: 199997
|
|
|
|
|
|
|
|
| |
MSAN detected a path that leaves DeprecatedStringLiteralToCharPtr uninitialized.
UserDefinedConversionSequence::First is a StandardConversionSequence that must
be initialized with setAsIdentityConversion.
llvm-svn: 199988
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Lift the getFunctionDecl() utility out of the parser into a general
Decl::getAsFunction() and use it to simplify other parts of the implementation.
Reduce isFunctionOrFunctionTemplate() to a simple type check that works the
same was as the other is* functions and move unwrapping of shadowed decls to
callers so it doesn't get run twice.
Shuffle around canSkipFunctionBody() to reduce virtual dispatch on ASTConsumer.
There's no need to query when we already know the body can't be skipped.
llvm-svn: 199794
|
|
|
|
| |
llvm-svn: 199703
|
|
|
|
| |
llvm-svn: 199699
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a perennial source of confusion in the clang type system: Declarations and
function prototypes have parameters to which arguments are supplied, so calling
these 'arguments' was a stretch even in C mode, let alone C++ where default
arguments, templates and overloading make the distinction important to get
right.
Readability win across the board, especially in the casting, ADL and
overloading implementations which make a lot more sense at a glance now.
Will keep an eye on the builders and update dependent projects shortly.
No functional change.
llvm-svn: 199686
|
|
|
|
|
|
|
|
| |
String literal to char* conversion is deprecated in C++03, and is removed in
C++11. We still accept this conversion in C++11 mode as an extension, if we find
it in the best viable function.
llvm-svn: 199513
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's been long-standing confusion over the role of these two options. This
commit makes the necessary changes to differentiate them clearly, following up
from r198936.
MicrosoftExt (aka. fms-extensions):
Enable largely unobjectionable Microsoft language extensions to ease
portability. This mode, also supported by gcc, is used for building software
like FreeBSD and Linux kernel extensions that share code with Windows drivers.
MSVCCompat (aka. -fms-compatibility, formerly MicrosoftMode):
Turn on a special mode supporting 'heinous' extensions for drop-in
compatibility with the Microsoft Visual C++ product. Standards-compilant C and
C++ code isn't guaranteed to work in this mode. Implies MicrosoftExt.
Note that full -fms-compatibility mode is currently enabled by default on the
Windows target, which may need tuning to serve as a reasonable default.
See cfe-commits for the full discourse, thread 'r198497 - Move MS predefined
type_info out of InitializePredefinedMacros'
No change in behaviour.
llvm-svn: 199209
|