This patch breaks up Wrap.h so that it does not have to include all of
the things, and renames it to CBindingWrapping.h. I also moved
CBindingWrapping.h into Support/.

This new file just contains

This patch breaks up Wrap.h so that it does not have to include all of
the things, and renames it to CBindingWrapping.h. I also moved
CBindingWrapping.h into Support/.

This new file just contains the macros for defining different wrap/unwrap
methods.

The calls to those macros, as well as any custom wrap/unwrap definitions
(like for array of Values for example), are put into corresponding C++
headers.

Doing this required some #include surgery, since some .cpp files relied
on the fact that including Wrap.h implicitly caused the inclusion of a
bunch of other things.

This also now means that the C++ headers will include their corresponding
C API headers; for example Value.h must include llvm-c/Core.h. I think
this is harmless, since the C API headers contain just external function
declarations and some C types, so I don't believe there should be any
nasty dependency issues here.

llvm-svn: 180881

show more ...

Move C++ code out of the C headers and into either C++ headers
or the C++ files themselves. This enables people to use
just a C compiler to interoperate with LLVM.

llvm-svn: 180063

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long

Move all of the header files which are involved in modelling the LLVM IR
into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

show more ...

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module

Use the new script to sort the includes of every file under lib.

Sooooo many of these had incorrect or strange main module includes.
I have manually inspected all of these, and fixed the main module
include to be the nearest plausible thing I could find. If you own or
care about any of these source files, I encourage you to take some time
and check that these edits were sensible. I can't have broken anything
(I strictly added headers, and reordered them, never removed), but they
may not be the headers you'd really like to identify as containing the
API being implemented.

Many forward declarations and missing includes were added to a header
files to allow them to parse cleanly when included first. The main
module rule does in fact have its merits. =]

llvm-svn: 169131

show more ...

Code Custodian:
- Widespread trailing space removal
- A dash of OCD spacing to block align enums
- joined a line that probably needed 80 cols a while back

llvm-svn: 168566

Add Module functions in place of module providers.

llvm-svn: 97608

Simplify.

llvm-svn: 96269

Kill ModuleProvider and ghost linkage by inverting the relationship between
Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules

Kill ModuleProvider and ghost linkage by inverting the relationship between
Modules and ModuleProviders. Because the "ModuleProvider" simply materializes
GlobalValues now, and doesn't provide modules, it's renamed to
"GVMaterializer". Code that used to need a ModuleProvider to materialize
Functions can now materialize the Functions directly. Functions no longer use a
magic linkage to record that they're materializable; they simply ask the
GVMaterializer.

Because the C ABI must never change, we can't remove LLVMModuleProviderRef or
the functions that refer to it. Instead, because Module now exposes the same
functionality ModuleProvider used to, we store a Module* in any
LLVMModuleProviderRef and translate in the wrapper methods. The bindings to
other languages still use the ModuleProvider concept. It would probably be
worth some time to update them to follow the C++ more closely, but I don't
intend to do it.

Fixes http://llvm.org/PR5737 and http://llvm.org/PR5735.

llvm-svn: 94686

show more ...

"In order to ease automatic bindings generation, it would be helpful if boolean values were distinguishable from integers. The attached patch introduces "typedef int LLVMBool;", and uses LLVMBool ins

"In order to ease automatic bindings generation, it would be helpful if boolean values were distinguishable from integers. The attached patch introduces "typedef int LLVMBool;", and uses LLVMBool instead of int throughout the C API, wherever a boolean value is called for."

Patch by James Y Knight!

llvm-svn: 93079

show more ...

Change llvm-c's ordering of contexts to make it consistent.

llvm-svn: 78656

Ack, missed one incompatibility.

llvm-svn: 74695

Restore other bits of the C API that I tore up. All pre-existing APIs default to using the
default global context, while new *InContext() APIs have been added that take a LLVMContextRef parameter.

Restore other bits of the C API that I tore up. All pre-existing APIs default to using the
default global context, while new *InContext() APIs have been added that take a LLVMContextRef parameter.

Apologies to anyone affected by this breakage.

llvm-svn: 74694

show more ...

Hold the LLVMContext by reference rather than by pointer.

llvm-svn: 74640

Add a pointer to the owning LLVMContext to Module. This requires threading LLVMContext through a lot
of the bitcode reader and ASM parser APIs, as well as supporting it in all of the tools.

Patches

Add a pointer to the owning LLVMContext to Module. This requires threading LLVMContext through a lot
of the bitcode reader and ASM parser APIs, as well as supporting it in all of the tools.

Patches for Clang and LLVM-GCC to follow.

llvm-svn: 74614

show more ...

Unbreak build with gcc 4.3: provide missed includes and silence most annoying warnings.

llvm-svn: 47367

Remove attribution from file headers, per discussion on llvmdev.

llvm-svn: 45418

Adding bindings for memory buffers and module providers. Switching
to exceptions rather than variants for error handling in Ocaml.

llvm-svn: 45226

Adding Ocaml bindings for the bitreader as requested by Sarah
Thompson. Usage should be something like this:

open Llvm
open Llvm_bitreader

match read_bitcode_file fn with
| Bitreader_failure msg

Adding Ocaml bindings for the bitreader as requested by Sarah
Thompson. Usage should be something like this:

open Llvm
open Llvm_bitreader

match read_bitcode_file fn with
| Bitreader_failure msg ->
prerr_endline msg
| Bitreader_success m ->
...;
dispose_module m

Compile with: ocamlc llvm.cma llvm_bitreader.cma
ocamlopt llvm.cmxa llvm_bitreader.cmxa

llvm-svn: 44824

show more ...