llvm-svn: 64156

to a class template. For example, the template-id 'vector<int>' now
has a nice, sugary type in the type system. What we can do now:

  - Parse template-ids like 'vector<int>' (where 'vector' names a
    class template) and form proper types for them in the type system.
  - Parse icky template-ids like 'A<5>' and 'A<(5 > 0)>' properly,
    using (sadly) a bool in the parser to tell it whether '>' should
    be treated as an operator or not.

This is a baby-step, with major problems and limitations:
  - There are currently two ways that we handle template arguments
  (whether they are types or expressions). These will be merged, and,
  most likely, TemplateArg will disappear.
  - We don't have any notion of the declaration of class template
  specializations or of template instantiations, so all template-ids
  are fancy names for 'int' :)

llvm-svn: 64153

llvm-svn: 64105

llvm-svn: 64100

llvm-svn: 64099

Add a simplified EmitJumpThroughFinally and use it in CGObjC in preparation of making it use the cleanup stack.

llvm-svn: 64098

llvm-svn: 64096

llvm-svn: 64095

If people could beat on it and let me know if there are any new
semantics required by newer language standards or DRs or any little
details I goofed on, I'd be happy to fix any issues found.

llvm-svn: 64079

llvm-svn: 64072

llvm-svn: 64069

llvm-svn: 64068

llvm-svn: 64064

llvm-svn: 64059

llvm-svn: 64053

llvm-svn: 64052

Add support for emitting cleanup blocks. Make EmitCompoundStatement emit cleanup blocks if necessary

llvm-svn: 64051

Add a simple RAII object, to be used for pushing a cleanup entry and make the insertion point be the cleanup block.

llvm-svn: 64048

correctly.  This should lay the ground work to throw the big switch
and start code gening break and continue in the presense of vlas.

llvm-svn: 64046

llvm-svn: 64043

llvm-svn: 64032

llvm-svn: 64031

llvm-svn: 64030

This will allow us to generate break and continue even if vlas are
involved without worry that we'll silently generate bad code.

llvm-svn: 64028

llvm-svn: 64021

llvm-svn: 64020

llvm-svn: 64014

 - Currently, this is producing poor code, but we prefer correctness
   to performance for now. Eventually we should be able to generally
   avoid having to set the alignment when we control the alignment of
   the alloca.

 - This knocks out 33/1000 failures on my single argument ABI tests,
   down to 22/1000 and 18 of these appear to be gcc bugs. Woot.

llvm-svn: 64001

non-empty.

llvm-svn: 63986

Now we can say 'hello world' objective-c style
in the nonfragile abi.

llvm-svn: 63981

llvm-svn: 63959

llvm-svn: 63952

llvm-svn: 63881

llvm-svn: 63879

llvm-svn: 63878

the documentation to the contrary).

llvm-svn: 63871

 - No intended functionality change, this is essentially enabling
   direct passing of complex and aggregate values, which no ABI is
   using.

llvm-svn: 63863

value.
 - No functionality change.

llvm-svn: 63859

 - No intended functionality change, all current ABI implementations
   were only using indirect for complex/aggregate types, which were
   being passed indirectly with the Direct ABIInfo kind.

llvm-svn: 63858

 - No (intended) functionality change, the semantic changes are to come.

llvm-svn: 63850