| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
-fapple-kext is an exception because calls will still go through
the vtable in that mode. Add a note to make the user aware of that.
PR: 23215
Differential Revision: http://reviews.llvm.org/D10935
llvm-svn: 242246
|
|
|
|
|
|
|
|
|
|
| |
The __kindof type qualifier can be applied to Objective-C object
(pointer) types to indicate id-like behavior, which includes implicit
"downcasting" of __kindof types to subclasses and id-like message-send
behavior. __kindof types provide better type bounds for substitutions
into unspecified generic types, which preserves more type information.
llvm-svn: 241548
|
|
|
|
| |
llvm-svn: 240353
|
|
|
|
|
|
|
|
|
|
|
|
| |
The patch is generated using this command:
$ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \
-checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \
work/llvm/tools/clang
To reduce churn, not touching namespaces spanning less than 10 lines.
llvm-svn: 240270
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This generalizes the checking of null arguments to also work with
values of pointer-to-function, reference-to-function, and block
pointer type, using the nullability information within the underling
function prototype to extend non-null checking, and diagnoses returns
of 'nil' within a function with a __nonnull return type.
Note that we don't warn about nil returns from Objective-C methods,
because it's common for Objective-C methods to mimic the nil-swallowing
behavior of the receiver by checking ostensibly non-null parameters
and returning nil from otherwise non-null methods in that
case.
It also diagnoses (via a separate flag) conversions from nullable to
nonnull pointers. It's a separate flag because this warning can be noisy.
llvm-svn: 240153
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The underlying problem in PR23823 already existed before my recent change
in r239558, but that change made it worse (failing not only for undeclared
symbols, but also failed overload resolution). This makes Clang not try to
delay the lookup in SFINAE context. I assume no current code is relying on
SFINAE working with lookups that need to be delayed, because that never
seems to have worked.
Differential Revision: http://reviews.llvm.org/D10417
llvm-svn: 239639
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR23810)
This patch does two things in order to enable compilation of the problematic code in PR23810:
1. In Sema::buildOverloadedCallSet, it postpones lookup for MS mode when no
viable candidate is found in the overload set. Previously, lookup would only
be postponed here if the overload set was empty.
2. Make BuildRecoveryCallExpr call Sema::DiagnoseEmptyLookup under more circumstances.
There is a comment in DiagnoseTwoPhaseLookup that says "Don't diagnose names we find in
classes; we get much better diagnostics for these from DiagnoseEmptyLookup." The problem
was that DiagnoseEmptyLookup might not get called later, and we failed to recover.
Differential Revision: http://reviews.llvm.org/D10369
llvm-svn: 239558
|
|
|
|
| |
llvm-svn: 236301
|
|
|
|
|
|
|
| |
is being accessed. Reviewed by Richard Smith.
rdar://20281011
llvm-svn: 234912
|
|
|
|
|
|
|
|
| |
integral promotion only if it converts to the underlying type or its promoted
type, not if it converts to the promoted type that the bitfield would have it
if were of the underlying type.
llvm-svn: 233457
|
|
|
|
| |
llvm-svn: 233234
|
|
|
|
|
|
| |
Patch by Joe Ranieri!
llvm-svn: 233085
|
|
|
|
|
|
|
|
| |
Patch by Richard (legalize at xmission dot com).
Differential Revision: http://reviews.llvm.org/D8155
llvm-svn: 231619
|
|
|
|
|
|
|
|
|
| |
We would wrongfully reject (a.~A)() in both the destructor and
pseudo-destructor cases.
This fixes PR22668.
llvm-svn: 230512
|
|
|
|
| |
llvm-svn: 230479
|
|
|
|
|
|
| |
conversion.
llvm-svn: 229792
|
|
|
|
|
|
| |
NFC.
llvm-svn: 229557
|
|
|
|
|
|
| |
Convert uses of those APIs into ranged for loops. NFC.
llvm-svn: 228404
|
|
|
|
| |
llvm-svn: 227267
|
|
|
|
|
|
| |
overlooked a few things, but this implementation comes straight from the DR resolution itself.
llvm-svn: 227224
|
|
|
|
|
|
|
| |
selects a deleted function, the outer function is still a candidate even though
the initialization sequence is "otherwise ill-formed".
llvm-svn: 227169
|
|
|
|
| |
llvm-svn: 226756
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The improved completion in call context now works with:
- Functions.
- Member functions.
- Constructors.
- New expressions.
- Function call expressions.
- Template variants of the previous.
There are still rough edges to be fixed:
- Provide support for optional parameters. (fix known)
- Provide support for member initializers. (fix known)
- Provide support for variadic template functions. (fix unknown)
- Others?
llvm-svn: 226670
|
|
|
|
|
|
|
| |
Move the logic for checking self moves into SemaChecking and add that function
to Sema since it is now used in multiple places.
llvm-svn: 225756
|
|
|
|
|
|
| |
__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
|