llvm-svn: 147139

\<newline><newline>

don't consume the second newline.

Thanks to David Blaikie for pointing out the crash!

llvm-svn: 147138

llvm-svn: 147137

definition would satisfy the constexpr requirements.

llvm-svn: 147128

declaration of that same class that either came from some other module
or occurred in the translation unit loading the module. In this case,
we need to merge the two redeclaration chains immediately so that all
such declarations have the same canonical declaration in the resulting
AST (even though they don't in the module files we've imported).

Focusing on Objective-C classes until I'm happy with the design, then
I'll both (1) extend this notion to other kinds of declarations, and
(2) optimize away this extra checking when we're not dealing with
modules. For now, doing this checking for PCH files/preambles gives us
better testing coverage.

llvm-svn: 147123

that the information collected by this method is a super set of the captured variables in BlockDecl.

llvm-svn: 147122

by string literals.

llvm-svn: 147120

llvm-svn: 147116

llvm-svn: 147112

llvm-svn: 147111

when the end of the buffer is immediately after an escaped newline.

Fixes http://llvm.org/PR10153.

llvm-svn: 147091

because of recent refactoring and one in the
rewriter.

llvm-svn: 147070

llvm-svn: 147068

llvm-svn: 147067

llvm-svn: 147066

so translate the range to file locations.

llvm-svn: 147058

llvm-svn: 147057

token locations as coming before the closing ')' of a function macro expansion.

Include a unit test for SourceManager.

llvm-svn: 147056

redeclaration chains: only ever have the reader search for
redeclarations of the first (canonical) declaration, since we only
ever record redeclaration ranges for the that declaration. Searching
for redeclarations of non-canonical declarations will never find
anything, so it's a complete waste of time.

llvm-svn: 147055

llvm-svn: 147048

llvm-svn: 147047

constant expressions.

llvm-svn: 147035

actually know about the other OSes on X86-32 besides Linux...

llvm-svn: 147034

 - constexpr function template instantiations
 - variables of reference type
 - constexpr variables

llvm-svn: 147031

llvm-svn: 147030

Fix a case where Expr::isConstantInitializer would return true for an expression we can't support.  In a slightly amusing twist, the case in question was already in the clang regression tests marked as a valid construct.  <rdar://problem/10020074>

llvm-svn: 147026

members of class templates so that their values can be used in ICEs. This
required reverting r105465, to get such instantiated members to be included in
serialized ASTs.

llvm-svn: 147023

on method declaration and definition if former is in
a system header. // rdar://10580333

llvm-svn: 147020

reasonable-looking but ill-formed for-range statement of the form:

  for (expression : expression)

llvm-svn: 147006

type is a pointer to const. (radar://10595327)

The regions corresponding to the pointer and reference arguments to
a function get invalidated by the calls since a function call can
possibly modify the pointed to data. With this change, we are not going
to invalidate the data if the argument is a pointer to const. This
change makes the analyzer more optimistic in reporting errors.
(Support for C, C++ and Obj C)

llvm-svn: 147002

in class method instead of crash. // rdar://10593227

llvm-svn: 146998

notify the AST deserialization listener so that the AST writer knows
that it can write the macro definition.

llvm-svn: 146994

llvm-svn: 146993

llvm-svn: 146988

Patch by Dimitry Andric!

llvm-svn: 146982

visibility restrictions. This ensures that all declarations of the
same entity end up in the same redeclaration chain, even if some of
those declarations aren't visible. While this may seem unfortunate to
some---why can't two C modules have different functions named
'f'?---it's an acknowedgment that a module does not introduce a new
"namespace" of names.

As part of this, stop merging the 'module-private' bit from previous
declarations to later declarations, because we want each declaration
in a module to stand on its own because this can effect, for example,
submodule visibility.

Note that this notion of names that are invisible to normal name
lookup but are available for redeclaration lookups is how we should
implement friend declarations and extern declarations within local
function scopes. I'm not tackling that problem now.

llvm-svn: 146980

the definition of that class. Fixes PR11613 / <rdar://problem/10604077>.

llvm-svn: 146976

Add AVX2 intrinsics for pavg, pblend, and pcmp instructions. Also remove unneeded builtins for SSE pcmp. Change SSE pcmpeqq and pcmpgtq to not use builtins and just use vector == and >.

llvm-svn: 146969

llvm-svn: 146967

Not long ago, I tightened up the type checking for pointer arguments of
Neon intrinsics to match the specifications provided by ARM.  One consequence
was that it became impossible to access the unaligned versions of a few
Neon load/store operations.  Since there are just a few of these intrinsics
where it makes a difference, I think it's better to relax the type checking
than to either introduce new non-standard unaligned intrinsics or to disallow
intrinsics for the unaligned operations.

llvm-svn: 146963