consider them when enumerating builtin operator candidates.

llvm-svn: 158293

We need an efficient mechanism to determine whether a defaulted default
constructor is constexpr, in order to determine whether a class is a literal
type, so keep the incrementally-built form on CXXRecordDecl. Remove the
on-demand computation of same, so that we only have one method for determining
whether a default constructor is constexpr. This doesn't affect correctness,
since default constructor lookup is much simpler than selecting a constructor
for copying or moving.

We don't need a corresponding mechanism for defaulted copy or move constructors,
since they can't affect whether a type is a literal type. Conversely, checking
whether such functions are constexpr can require non-trivial effort, so we defer
such checks until the copy or move constructor is required.

Thus we now only compute whether a copy or move constructor is constexpr on
demand, and only compute whether a default constructor is constexpr in advance.
This is unfortunate, but seems like the best solution.

llvm-svn: 158290

an explicitly-defaulted default constructor would be constexpr. This is
necessary in weird (but well-formed) cases where a class has more than one copy
or move constructor.

Cleanup of now-unused parts of CXXRecordDecl to follow.

llvm-svn: 158289

initialization, and use that information to produce the right kind of
initialization during template instantiation.

llvm-svn: 158288

llvm-svn: 158241

This could happen for cases like this:

- (NSArray *)getAllNames:(NSArray *)images {
  NSMutableArray *results = [NSMutableArray array];
  for (auto img in images) {
    [results addObject:img.name];
  }
  return results;
}

Here the property access will fail because 'img' has type 'id', rather than,
say, NSImage.

This warning will not fire in templated code, since the 'id' could have
come from a template parameter.

llvm-svn: 158239

typo-correction after a scope specifier.

llvm-svn: 158231

Objective-C literals conceptually always create new objects, but may be
optimized by the compiler or runtime (constant folding, singletons, etc).
Comparing addresses of these objects is relying on this optimization
behavior, which is really an implementation detail.

In the case of == and !=, offer a fixit to a call to -isEqual:, if the
method is available. This fixit is directly on the error so that it is
automatically applied.

Most of the time, this is really a newbie mistake, hence the fixit.

llvm-svn: 158230

variable which wasn't removed when the original patch was committed.

llvm-svn: 158225

AST: For auto-synthesized ivars give them the location of the related
property (previously they had no source location). This allows them
to be indexed by libclang.

libclang: Make sure synthesized ivars are indexed before the methods that
may reference them.

Fixes rdar://11607001.

llvm-svn: 158189

definitions of such members are prohibited, not mere declarations.

llvm-svn: 158186

feedback from Doug Gregor.

llvm-svn: 158185

nested name specifiers in addition to the function's identifier when the
correction has a different nested name specifier.

llvm-svn: 158178

correction to use for an invalid function redeclaration.

llvm-svn: 158177

The integral APSInt value is now stored in a decomposed form and the backing
store for large values is allocated via the ASTContext. This way its not
leaked as TemplateArguments are never destructed when they are allocated in
the ASTContext. Since the integral data is immutable it is now shared between
instances, making copying TemplateArguments a trivial operation.

Currently getting the integral data out of a TemplateArgument requires creating
a new APSInt object. This is cheap when the value is small but can be expensive
if it's not. If this turns out to be an issue a more efficient accessor could
be added.

llvm-svn: 158150

Before, the note showed the location where you could insert __bridge variants,
but the actual fixit edit came after the cast.

No functionality change.

llvm-svn: 158131

This was a problem for people who write 'return(result);'

Also fix ARCMT's corresponding code, though there's no test case for this
because implicit casts like this are rejected by the migrator for being
ambiguous, and explicit casts have no problem.

<rdar://problem/11577346>

llvm-svn: 158130

are otherwise too short to try to correct.

The TODOs added to two of the tests are for existing deficiencies in the
typo correction code that could be exposed by using longer identifiers.

llvm-svn: 158109

In addition, I've made the pointer and reference typedef 'void' rather than T*
just so they can't get misused. I would've omitted them entirely but
std::distance likes them to be there even if it doesn't use them.

This rolls back r155808 and r155869.

Review by Doug Gregor incorporating feedback from Chandler Carruth.

llvm-svn: 158104

llvm-svn: 158086

unused private fields of classes that are fully defined in the current
translation unit.

llvm-svn: 158054

the overriding deprecated/unavailable method.
// rdar://11475360

llvm-svn: 158022

Within the guts of CheckFormatHandler, the IsObjCLiteral flag was being used in
two ways: to see if null bytes were allowed, and to see if the '%@' specifier
is allowed.* The former usage has been changed to an explicit test and the
latter pushed down to CheckPrintfHandler and renamed ObjCContext, since it
applies to CFStrings as well.

* This also changes how wide chars are interpreted; in OS X Foundation, the
wide character type is 'unichar', a typedef for short, rather than wchar_t.

llvm-svn: 157968

llvm-svn: 157961

temporary or an array subobject of a class temporary, and the resulting value
is used to initialize a pointer which outlives the temporary. Such a pointer
is always left dangling after the initialization completes and the array's
lifetime ends.

In order to detect this situation, this change also adds an
LValueClassification of LV_ArrayTemporary for temporaries of array type which
aren't subobjects of class temporaries. These occur in C++11 T{...} and GNU C++
(T){...} expressions, when T is an array type. Previously we treated the former
as a generic prvalue and the latter as a class temporary.

llvm-svn: 157955

message receiver is 'weak' property.
// rdar://10225276

llvm-svn: 157946

llvm-svn: 157943

involving 'restrict', place restrict on the pointer type rather than
on the pointee type. Also make sure that we gather restrict from the
pointer type. Fixes PR12854 and the major part of PR11093.

llvm-svn: 157910

Before:
test.cc:2:18: note: place parentheses around the == expression to silence this warning
  if (0 == flags & 0xdd)
                 ^
                   (   )

Now:
test.cc:2:18: note: place parentheses around the == expression to silence this warning
  if (0 == flags & 0xdd)
                 ^
      (         )

llvm-svn: 157897

llvm-svn: 157886

Implementation of a "soft opt-in" option for -Wimplicit-fallthrough diagnostics: -Wimplicit-fallthrough-per-method

llvm-svn: 157871

but different nested name specifiers to quietly clobber each other so
only one remains if they do not refer to the same NamedDecl. Fixes
PR12951.

llvm-svn: 157823

when migrating.

rdar://11569198

llvm-svn: 157785

Anonymous union members within a struct are now properly handled as an unevaluated field in C++11 mode.  This fixes PR12866.

llvm-svn: 157784

the confusion among all of the uses of Best* in relation to the set of
possible typo correction results. Also add a method to return the set of
typo corrections that have the single best edit distance--it returns the
second half of the first pair in TypoEditDistanceMap (with
getBestEditDistance already returning the first half).

llvm-svn: 157781

have correct pointer type or issue error,
instead of crashing in IRGen. // rdar:// 11569860

llvm-svn: 157780

As per comments following r157659.

llvm-svn: 157722

This is a large class of false positives where anonymous enums are used to
declare constants (see Clang's Diagnostics.h for example). A small number of
true positives could probably be found in this bucket by still warning if the
anonymous enum is used in a declarator (enum { ... } x;) but so far we don't
believe this to be a source of significant benefit so I haven't bothered to
preserve those cases.

General offline review/acknowledgment by rtrieu.

llvm-svn: 157713

and reported as PR12959. // rdar://11499742

llvm-svn: 157697

llvm-svn: 157667