type, even when in the struct case.  This was one root issue that was
causing type mismatches throughout the compiler.

llvm-svn: 134862

conservative when converting a functiontype to IR when in a "pointer within
a struct" context.  This has the unfortunate sideeffect of compiling all 
function pointers inside of structs into "{}*" which, though correct, is
ugly.  This has the positive side effect of being correct, and it is pretty
straight-forward to improve on this.

llvm-svn: 134861

do an explicit bitcast to whatever ConvertType produces.  This will
go with the next patch.

llvm-svn: 134860

llvm-svn: 134859

llvm-svn: 134858

- Add getCompl() method.

llvm-svn: 134857

llvm-svn: 134856

llvm-svn: 134855

llvm-svn: 134854

it is a predicate, not an action.  Change the return type to be a bool,
not the incomplete member.  Enhace it to detect the recursive compilation
case, allowing us to compile Eli's testcase on llvmdev:

struct T {
 struct T (*p)(void);
} t;

into:

%struct.T = type { {}* }

@t = common global %struct.T zeroinitializer, align 8

llvm-svn: 134853

PR10292 doesn't show that the loads don't alias
the allocas.

llvm-svn: 134852

llvm-svn: 134851

llvm-svn: 134850

llvm-svn: 134849

llvm-svn: 134848

llvm-svn: 134847

Made it so that you can create synthetic children of array
value objects. This is for creating array members when the
array index is out of range. This comes in handy when you have
a structure definition like:

struct Collection
{
    uint32_t count;
    Item array[0];
};
"array" has 1 item, but many times in practice there are more
items in "item_array".

This allows you to do:

(lldb) target variable g_collection.array[3]

To implement this, the get child at index has been modified
to have a "ignore_array_bounds" boolean that can be set to true.

llvm-svn: 134846

in the first place. http://llvm.org/PR10312.

llvm-svn: 134845

This is a new mode of migration, where we avoid modifying the original files but
we emit temporary files instead.

<path> will be used to keep migration process metadata. Currently the temporary files
that are produced are put in the system's temp directory but we can put them
in the <path> if is necessary.

Also introduce new ARC migration functions in libclang whose only purpose,
currently, is to accept <path> and provide pairs of original file/transformed file
to map from the originals to the files after transformations are applied.

Finally introduce the c-arcmt-test utility that exercises the new libclang functions,
update arcmt-test, and add tests for the whole process.

rdar://9735086.

llvm-svn: 134844

llvm-svn: 134843

llvm-svn: 134842

the enum has already been converted.  If not, there cannot be any types
built on top of it, so there is no need to flush the cache.

llvm-svn: 134841

llvm-svn: 134840

module operations that operate on type names are gone.

llvm-svn: 134839

type refinement.  Zap them now that type refinement is toast.

llvm-svn: 134837

llvm-svn: 134836

their names, we don't need a module around to print them.

llvm-svn: 134835

llvm-svn: 134833

llvm-svn: 134832

llvm-svn: 134831

patch brings numerous advantages to LLVM.  One way to look at it
is through diffstat:
 109 files changed, 3005 insertions(+), 5906 deletions(-)

Removing almost 3K lines of code is a good thing.  Other advantages
include:

1. Value::getType() is a simple load that can be CSE'd, not a mutating
   union-find operation.
2. Types a uniqued and never move once created, defining away PATypeHolder.
3. Structs can be "named" now, and their name is part of the identity that
   uniques them.  This means that the compiler doesn't merge them structurally
   which makes the IR much less confusing.
4. Now that there is no way to get a cycle in a type graph without a named
   struct type, "upreferences" go away.
5. Type refinement is completely gone, which should make LTO much MUCH faster
   in some common cases with C++ code.
6. Types are now generally immutable, so we can use "Type *" instead 
   "const Type *" everywhere.

Downsides of this patch are that it removes some functions from the C API,
so people using those will have to upgrade to (not yet added) new API.  
"LLVM 3.0" is the right time to do this.

There are still some cleanups pending after this, this patch is large enough
as-is.

llvm-svn: 134829

llvm-svn: 134827

llvm-svn: 134826

breakpoint. I haven't been able to see this breakpoint get hit yet
so I still have testing I need to do with the kernel dynamic loader.

llvm-svn: 134825

thanks to a nice clang warning!

llvm-svn: 134824

variable where we were using a static cast when we shouldn't have been.
Fixed another array related issue where we weren't looking through a typedef.

llvm-svn: 134823

llvm-svn: 134822

used by the new bitcode reader.

llvm-svn: 134821

llvm-svn: 134820

llvm-svn: 134819