as output.  Needed for (functional) correctness in inline asm,
and should be generally beneficial.  7361612.

llvm-svn: 95050

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

any other member.

llvm-svn: 95047

when the cast is extending.

llvm-svn: 95046

generalize it to handle more cases.

llvm-svn: 95045

llvm-svn: 95044

llvm-svn: 95043

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

llvm-svn: 95041

don't use TargetData here.

llvm-svn: 95040

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

llvm-svn: 95036

llvm-svn: 95035

merely stubs out the blocks-based disassembly functions
if the library wasn't built with blocks, which allows a
constant .exports file and also properly deals with
situations in which the compiler used to build a client
is different from the compiler used to build the library.

llvm-svn: 95034

The MCStreamer based assemblers will take over for this functionality.

llvm-svn: 95033

a test for access declarations and remove a (broken) test for removal
of default arguments.

llvm-svn: 95032

  - 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

directories (like, oh, say, any multistage build)

llvm-svn: 95028

llvm-svn: 95027

llvm-svn: 95026

Rn operand.

llvm-svn: 95025

target platform, depending on whether the target
supports the blocks API or not

llvm-svn: 95024

llvm-svn: 95023

llvm-svn: 95022

llvm-svn: 95021

llvm-svn: 95018

llvm-svn: 95017

llvm-svn: 95016

llvm-svn: 95014

llvm-svn: 95012

because some platforms don't support blocks and then
break because the symbols aren't present

llvm-svn: 95011

llvm-svn: 95010

llvm-svn: 95009

llvm-svn: 95008

disabled by default.  This divides the existing load PRE code into 2 phases:
first it checks that it is safe to move the load to each of the predecessors
where it is unavailable, and then if it is safe, the code is changed to move
the load.  Radar 7571861.

llvm-svn: 95007