diagnostic emission. The fixit hint, when suggested, typically has
nothing to do with the nature or form of the reference.

llvm-svn: 128899

extracts a function to handle the emission of the diagnostic separately
from the walking over the set of uninitialized uses.

Also updates the naming used within this extracted function to be a bit
more consistent with the rest of Clang's naming patterns.

The next step will be breaking this apart so that we can go through
different functions rather than tracking so many boolean variables.

llvm-svn: 128898

  int x = x;

GCC disables its warnings on this construct as a way of indicating that
the programmer intentionally wants the variable to be uninitialized.
Only the warning on the initializer is turned off in this iteration.

This makes the code a lot more ugly, but starts commenting the
surprising behavior here. This is a WIP, I want to refactor it
substantially for clarity, and to determine whether subsequent warnings
should be suppressed or not.

llvm-svn: 128894

I think this moves the code in the desired direction of the new style
recommendations (and style conventional in Clang), but if anyone prefers
the previous style, or has other suggestions just chime in and I'll
follow up.

llvm-svn: 128878

is a single implementation. No functionality change intended.

llvm-svn: 128877

Fix PR 9626 (duplicated self-init warnings under -Wuninitialized) with numerous CFG and UninitializedValues analysis changes:

1) Change the CFG to include the DeclStmt for conditional variables, instead of using the condition itself as a faux DeclStmt.
2) Update ExprEngine (the static analyzer) to understand (1), so not to regress.
3) Update UninitializedValues.cpp to initialize all tracked variables to Uninitialized at the start of the function/method.
4) Only use the SelfReferenceChecker (SemaDecl.cpp) on global variables, leaving the dataflow analysis to handle other cases.

The combination of (1) and (3) allows the dataflow-based -Wuninitialized to find self-init problems when the initializer
contained control-flow.

llvm-svn: 128858

-Wuninitialized: use "self-init" warning when issue uninitialized values warnings from the dataflow analysis that include within the initializer of a variable.

llvm-svn: 128843

-Wuninitialized: don't issue fixit for initializer if a variable declaration already has an initializer.

llvm-svn: 128838

When emitting a "too many arguments to function call..." error, also include a note with a location for the function prototype.

llvm-svn: 128833

I'm pretty sure this is the right fix, but I would appreciate it if someone
else would double-check.

llvm-svn: 128806

llvm-svn: 128780

location into a TemplateSpecializationTypeLoc. These were found using
a hand-written program to inspect every source location in
TemplateSpecializationTypeLocs and Valgrind. I don't know of any way to
test them in Clang's existing test suite sadly.

Example code that triggers the ElaboratedType case:
  template <typename T> struct X1 {
    template <typename U> struct X1_1 {
      int x;
    };
  };

  template <typename T, typename U> struct X2 {
    typename X1<T>::template X1_1<U> B;
  };

  X2<char, int> x2;

The other fix was simply spotted by inspection. I audited all constructions of
[Dependent]TemplateSpecializationTypeLocs in TreeTransform.h, and the rest set
the TemplateNameLoc properly.

llvm-svn: 128702

Make ChainedIncludesSource an ExternalSemaSource, otherwise initialization of the ASTReader is incomplete, leading to errors like not realizing std::type_info is already defined.

llvm-svn: 128664

Add a test case for synthesize ivar. // rdar://9070460

llvm-svn: 128554

assert-less codepath marginally more efficient.

llvm-svn: 128472

This fixes a bunch of errors when compiling MSVC header files with the -DDLL flag.

llvm-svn: 128457

when the resolution took place due to a single template specialization
being named with an explicit template argument list. In this case, the
"resolution" doesn't take into account the target type at all, and
therefore can take place for functions, static member functions, and
*non-static* member functions. The latter weren't being properly checked
and their proper form enforced in this scenario. We now do so.

The result of this last form slipping through was some confusing logic
in IsStandardConversion handling of these resolved address-of
expressions which eventually exploded in an assert. Simplify this logic
a bit and add some more aggressive asserts to catch improperly formed
expressions getting into this routine.

Finally add systematic testing of member functions, both static and
non-static, in the various forms they can take. One of these is
essentially PR9563, and this commit fixes the crash in that PR. However,
the diagnostics for this are still pretty terrible. We at least are now
accepting the correct constructs and rejecting the invalid ones rather
than accepting invalid or crashing as before.

llvm-svn: 128456

Don't do the checks of Sema::DiagnoseEqualityWithExtraParens() on type-dependent expressions. Fixes rdar://9027658.

llvm-svn: 128437

an executable test to llvm test suite.
// rdar://9070460.

llvm-svn: 128435

llvm-svn: 128427

// rdar://9181463

llvm-svn: 128410

llvm-svn: 128401

functionality changed.

llvm-svn: 128396

an objc method. Fixes // rdar://9181463

llvm-svn: 128389

AltiVec vector comparison logic now affect only vectors of fundamental AltiVec vector types. It fixes bug 9347. 

llvm-svn: 128381

This is basically the same idea as the warning on uninitialized uses of
fields within an initializer list. As such, it is on by default and
under -Wuninitialized.

Original patch by Richard Trieu, with some massaging from me on the
wording and grouping of the diagnostics.

llvm-svn: 128376

supported: AltiVec vector initialization with a single literal according to PIM section 2.5.1 - after initialization all elements have the value specified by the literal

llvm-svn: 128375

specifications within the global scope, from Elliot Glaysher.

llvm-svn: 128352

from an objective-c message: // rdar://9005189

llvm-svn: 128348

llvm-svn: 128339

platform implies default visibility. To achieve these, refactor our
lookup of explicit visibility so that we search for both an explicit
VisibilityAttr and an appropriate AvailabilityAttr, favoring the
VisibilityAttr if it is present.

llvm-svn: 128336

'unavailable' argument, which specifies that the declaration to which
the attribute appertains is unavailable on that platform.

llvm-svn: 128329

without a warning.

llvm-svn: 128328

usually useless, but not always.

llvm-svn: 128326

llvm-svn: 128324

llvm-svn: 128280

llvm-svn: 128279

Get rid of handling of the 'explicit' keyword from class-head. We still parse it though, although that will change shortly.

llvm-svn: 128277

llvm-svn: 128271

llvm-svn: 128253