clang.cpp

llvm-svn: 67890

LHS type and the computation result type; this encodes information into 
the AST which is otherwise non-obvious.  Fix Sema to always come up with the 
right answer for both of these types.  Fix IRGen and the analyzer to 
account for these changes.  This fixes PR2601.  The approach is inspired 
by PR2601 comment 2.

Note that this changes real *= complex in CodeGen from a silent 
miscompilation to an explicit error.

I'm not really sure that the analyzer changes are correct, or how to 
test them... someone more familiar with the analyzer should check those 
changes.

llvm-svn: 67889

llvm-svn: 67887

llvm-svn: 67886

syntax into extension warnings, and provide code-modification hints
showing how to fix the problem.

llvm-svn: 67885

llvm-svn: 67883

llvm-svn: 67881

llvm-svn: 67880

default constructor produces an uninitialized APInt.
This fixes PR3896.

llvm-svn: 67879

GNU-style array designators, causing us to emit broken initializers.

llvm-svn: 67878

NestedNameSpecifiers without causing problems for the FoldingSet that
contains them.

llvm-svn: 67877

Do not emit debug information for variables while generating optimized code.  The llvm optimizer and code generator are not yet ready to support optimized code debugging.

llvm-svn: 67876

instantiation for C++ typename-specifiers such as

  typename T::type

The parsing of typename-specifiers is relatively easy thanks to
annotation tokens. When we see the "typename", we parse the
typename-specifier and produce a typename annotation token. There are
only a few places where we need to handle this. We currently parse the
typename-specifier form that terminates in an identifier, but not the
simple-template-id form, e.g.,

  typename T::template apply<U, V>

Parsing of nested-name-specifiers has a similar problem, since at this
point we don't have any representation of a class template
specialization whose template-name is unknown.

Semantic analysis is only partially complete, with some support for
template instantiation that works for simple examples. 

llvm-svn: 67875

llvm-svn: 67874

llvm-svn: 67872

llvm-svn: 67871

llvm-svn: 67870

successor, using 'getEnclosingStmt()' to have the end location be the top-level
Stmt* enclosing the target Expr*.

llvm-svn: 67869

remove a redundant error in CodeGen.

llvm-svn: 67868

rather nasty, but I can't think of a better fix off the top of my head.

llvm-svn: 67867

PathDiagnosticLocation.

llvm-svn: 67866

instead of a load + large inlined switch.

llvm-svn: 67864

llvm-svn: 67863

llvm-svn: 67862

llvm-svn: 67861

It is OK to cast to a private base class if the current member belongs to the class that the private base class is a base of:

class A {};
class B : private A {
  void f(B *b) { A* a = b; }
};

llvm-svn: 67860

Add a Class field to the base path element structure. This holds the record decl of the class taht the base is a base of.

llvm-svn: 67859

llvm-svn: 67858

ir gen. No intended change in functionality.

llvm-svn: 67857

llvm-svn: 67856

llvm-svn: 67855

llvm-svn: 67854

llvm-svn: 67850

unrelated debugging output happening to contain the string "store".

llvm-svn: 67849

llvm-svn: 67848

start-end points, where start and end are source ranges.

llvm-svn: 67847

llvm-svn: 67846

llvm-svn: 67845

causing a bootstrap failure.  Bootstraps here on
x86-32-linux and x86-64-linux.  Requested by the
author Gabor Greif who says that a bug that might
have been causing the failure has since been fixed.

llvm-svn: 67844

improve TLS support (see http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090309/075220.html), but that code is VERY brittle.

This patch just makes it a bit more resistant.

llvm-svn: 67843