llvm-svn: 67911

llvm-svn: 67910

llvm-svn: 67909

llvm-svn: 67908

llvm-svn: 67907

just a wrapper around ASTContext.

llvm-svn: 67906

llvm-svn: 67905

llvm-svn: 67904

llvm-svn: 67903

llvm-svn: 67902

etc., so that the "body" is always considered a top-level statement for edge
transitions (even if it is an expression).

llvm-svn: 67901

llvm-svn: 67900

llvm-svn: 67899

types don't get generated when blocks aren't used.

llvm-svn: 67898

llvm-svn: 67897

llvm-svn: 67896

llvm-svn: 67895

happy with just ASTContext, they don't need a TU.

llvm-svn: 67894

llvm-svn: 67893

llvm-svn: 67892

llvm-svn: 67891

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