Set the correct vtable pointers _before_ generating code for any member initializers. Fixes about ~2000 clang/LLVM tests in the clang-on-clang build.

llvm-svn: 95116

llvm-svn: 95110

llvm-svn: 95106

llvm-svn: 95104

Check for redefinitions in MergeVarDecl. This finds redefinitions of globals without an initializer in C++ and thus fixes PR5451.

llvm-svn: 95098

Fixes radar 7589414.

llvm-svn: 95097

llvm-svn: 95096

type qualifiers and type specifiers in any order.   For example,
this is valid: struct x {...} typedef y;

This fixes PR6208.

llvm-svn: 95094

this is still a popular thing to do.

llvm-svn: 95093

unused variable warning.

llvm-svn: 95085

llvm-svn: 95079

magnitude clearer.

llvm-svn: 95078

Eliminates a lot of spurious global initializers, fixing PR6205.

llvm-svn: 95077

llvm-svn: 95076

UnresolvedMemberExpr and employ it in a few places where it's useful.

llvm-svn: 95072

llvm-svn: 95066

llvm-svn: 95063

as an argument during overload resolution.

llvm-svn: 95057

arguments.  Fix a bug where incomplete explicit specializations were being
passed through as legitimate.  Fix a bug where the absence of an explicit
specialization in an overload set was causing overall deduction to fail.

Fixes PR6191.

llvm-svn: 95052

This is to address a serious performance problem observed when running
'clang -fsyntax-only' on really broken source files.  In one case,
repeatedly calling CorrectTypo() caused one source file to be rejected
after 2 minutes instead of 1 second.

This patch causes typo correction to take neglible time on that file
while still providing correction results for the first 20 cases.  I
felt this was a reasonable number for moderately broken source files.

I don't claim this is the best solution.  Comments welcome.  It is
necessary for us to address this issue because it is a serious
performance problem.

llvm-svn: 95049

'Pred' to 'Dst' for cases we currently don't handle.  This fixes
<rdar://problem/7593875>.

llvm-svn: 95048

forgetting a ';' at the end of a struct.  For something like:

class c {
}
void foo() {}

we now produce:

t.cc:3:2: error: expected ';' after class
}
 ^
 ;

instead of:

t.cc:4:1: error: cannot combine with previous 'class' declaration specifier
void foo() {}
^
t.cc:2:7: error: 'class c' can not be defined in the result type of a function
class c {
      ^

GCC produces:

t.cc:4: error: new types may not be defined in a return type
t.cc:4: note: (perhaps a semicolon is missing after the definition of ‘c’)
t.cc:4: error: two or more data types in declaration of ‘foo’

I *think* I got the follow set right, but if I forgot anything, we'll start 
getting spurious "expected ';' after class" errors, let me know if you see
any.

llvm-svn: 95042

t.cc:4:3: error: expected ';' at end of declaration list
  int y;
  ^
t.cc:6:1: error: expected ';' at end of declaration list
};
^

After:

t.cc:3:8: error: expected ';' at end of declaration list
  int x
       ^
       ;
t.cc:5:8: error: expected ';' at end of declaration list
  int z
       ^
       ;

llvm-svn: 95039

t.c:4:3: error: expected ';' at end of declaration list
  int y;
  ^
t.c:4:8: warning: extra ';' inside a struct or union
  int y;
       ^
t.c:6:1: warning: expected ';' at end of declaration list
};
^

After:

t.c:3:8: error: expected ';' at end of declaration list
  int x  // expected-error {{expected ';' at end of declaration list}}
       ^
       ;
t.c:5:8: warning: expected ';' at end of declaration list
  int z
       ^
       ;

llvm-svn: 95038

Hoist diagnostic generation in ReturnStackAddressChecker into a separate method.  No functionality change.

llvm-svn: 95037

  - In C++, prior to the closing '}', set the type of enumerators
    based on the type of their initializer. Don't perform unary
    conversions on the enumerator values.
  - In C++, handle overflow when an enumerator has no initializer and
    its value cannot be represented in the type of the previous
    enumerator.
  - In C, handle overflow more gracefully, by complaining and then
    falling back to the C++ rules.
  - In C, if the enumerator value is representable in an int, convert the
    expression to the type 'int'.

Fixes PR5854 and PR4515.

llvm-svn: 95031

llvm-svn: 95030

llvm-svn: 95029

llvm-svn: 95026

llvm-svn: 95023

llvm-svn: 95016

llvm-svn: 95010

llvm-svn: 95009

llvm-svn: 95008

llvm-svn: 95006

llvm-svn: 95005

llvm-svn: 95004

by setting the section of the generated global.  This is an
optimization done by the code generator, and the code being
removed didn't handle the case when the string contained an
embedded nul (which the code generator does correctly 
handle).  This is rdar://7589850

llvm-svn: 95003

In C++, an initializer on a variable doesn't necessarily mean it's the definition. With that in mind, rename getDefinition to getAnyInitializer (to distinguish it from getInit) and reimplement it in terms of isThisDeclarationADefinition. Update all code to use this new function.

llvm-svn: 94999

emmintrin looks ok.

llvm-svn: 94998