summaryrefslogtreecommitdiff
path: root/llvm/lib/Bitcode/Reader/BitReader.cpp
AgeCommit message (Collapse)Author
2022-02-07Cleanup LLVMBitcode headersserge-sans-paille
Major user-facing changes: llvm/Bitcode/BitcodeReader.h no longer includes llvm/IR/ModuleSummaryIndex.h Some statistics: clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Bitcode/Reader/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l after: 493335 before: 539640 Discourse thread on the topic: https://discourse.llvm.org/t/include-what-you-use-include-cleanup/ Differential Revision: https://reviews.llvm.org/D119091
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2017-12-13Remove redundant includes from lib/Bitcode.Michael Zolotukhin
llvm-svn: 320618
2016-11-14Add explicit (void) cast to unused unique_ptr::release() resultsEric Fiselier
Summary: This patch adds explicit `(void)` casts to discarded `release()` calls to suppress -Wunused-result. This patch fixes *all* warnings are generated as a result of [applying `[[nodiscard]]` within libc++](https://reviews.llvm.org/D26596). Similar fixes were applied to Clang in r286796. Reviewers: chandlerc, dberris Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D26598 llvm-svn: 286797
2016-11-13Bitcode: Change module reader functions to return an llvm::Expected.Peter Collingbourne
Differential Revision: https://reviews.llvm.org/D26562 llvm-svn: 286752
2016-11-11Split Bitcode/ReaderWriter.h into separate reader and writer headersTeresa Johnson
Summary: Split ReaderWriter.h which contains the APIs into both the BitReader and BitWriter libraries into BitcodeReader.h and BitcodeWriter.h. This is to address Chandler's concern about sharing the same API header between multiple libraries (BitReader and BitWriter). That concern is why we create a single bitcode library in our downstream build of clang, which led to r286297 being reverted as it added a dependency that created a cycle only when there is a single bitcode library (not two as in upstream). Reviewers: mehdi_amini Subscribers: dlj, mehdi_amini, llvm-commits Differential Revision: https://reviews.llvm.org/D26502 llvm-svn: 286566
2016-11-08IR, Bitcode: Change bitcode reader to no longer own its memory buffer.Peter Collingbourne
Unique ownership is just one possible ownership pattern for the memory buffer underlying the bitcode reader. In practice, as this patch shows, ownership can often reside at a higher level. With the upcoming change to allow multiple modules in a single bitcode file, it will no longer be appropriate for modules to generally have unique ownership of their memory buffer. The C API exposes the ownership relation via the LLVMGetBitcodeModuleInContext and LLVMGetBitcodeModuleInContext2 functions, so we still need some way for the module to own the memory buffer. This patch does so by adding an owned memory buffer field to Module, and using it in a few other places where it is convenient. Differential Revision: https://reviews.llvm.org/D26384 llvm-svn: 286214
2016-04-14Remove every uses of getGlobalContext() in LLVM (but the C API)Mehdi Amini
At the same time, fixes InstructionsTest::CastInst unittest: yes you can leave the IR in an invalid state and exit when you don't destroy the context (like the global one), no longer now. This is the first part of http://reviews.llvm.org/D19094 From: Mehdi Amini <mehdi.amini@apple.com> llvm-svn: 266379
2015-12-18Deprecate a few C APIs.Rafael Espindola
This deprecates: * LLVMParseBitcode * LLVMParseBitcodeInContext * LLVMGetBitcodeModuleInContext * LLVMGetBitcodeModule They are replaced with the functions with a 2 suffix which do not record a diagnostic. llvm-svn: 256065
2015-12-18clang-format to reduce diff in another patch.Rafael Espindola
llvm-svn: 255999
2015-12-18Fix error handling in LLVMGetBitcodeModuleInContext.Rafael Espindola
It was not setting OutMessage. llvm-svn: 255998
2015-12-18Reorganize the C API headers to improve build times.Eric Christopher
Type specific declarations have been moved to Type.h and error handling routines have been moved to ErrorHandling.h. Both are included in Core.h so nothing should change for projects directly including the headers, but transitive dependencies may be affected. llvm-svn: 255965
2015-12-17Drop function that are deprecated since 2010.Rafael Espindola
These functions were deprecated in r97608. llvm-svn: 255927
2015-12-14Use diagnostic handler in the LLVMContextRafael Espindola
This patch converts code that has access to a LLVMContext to not take a diagnostic handler. This has a few advantages * It is easier to use a consistent diagnostic handler in a single program. * Less clutter since we are not passing a handler around. It does make it a bit awkward to implement some C APIs that return a diagnostic string. I will propose new versions of these APIs and deprecate the current ones. llvm-svn: 255571
2015-06-16Return a unique_ptr from getLazyBitcodeModule and parseBitcodeFile. NFC.Rafael Espindola
llvm-svn: 239858
2015-02-03Propagate a better error message to the C api.Rafael Espindola
llvm-svn: 227934
2015-02-03Use a non-fatal diag handler in the C API. FIxes PR22368.Rafael Espindola
llvm-svn: 227903
2014-09-03Pass a && to getLazyBitcodeModule.Rafael Espindola
This forces callers to use std::move when calling it. It is somewhat odd to have code with std::move that doesn't always move, but it is also odd to have code without std::move that sometimes moves. llvm-svn: 217049
2014-08-26Pass a std::unique_ptr<MemoryBuffer>& to getLazyBitcodeModule.Rafael Espindola
By taking a reference we can do the ownership transfer in one place instead of expecting every caller to do it. llvm-svn: 216492
2014-08-26Pass a MemoryBufferRef when we can avoid taking ownership.Rafael Espindola
The attached patch simplifies a few interfaces that don't need to take ownership of a buffer. For example, both parseAssembly and parseBitcodeFile will parse the entire buffer before returning. There is no need to take ownership. Using a MemoryBufferRef makes it obvious in the type signature that there is no ownership transfer. llvm-svn: 216488
2014-06-13Remove 'using std::errro_code' from lib.Rafael Espindola
llvm-svn: 210871
2014-06-12Don't use 'using std::error_code' in include/llvm.Rafael Espindola
This should make sure that most new uses use the std prefix. llvm-svn: 210835
2014-04-15[C++11] More 'nullptr' conversion. In some cases just using a boolean check ↵Craig Topper
instead of comparing to nullptr. llvm-svn: 206252
2014-01-15Make parseBitcodeFile return an ErrorOr<Module *>.Rafael Espindola
llvm-svn: 199279
2014-01-13Update getLazyBitcodeModule to use ErrorOr for error handling.Rafael Espindola
llvm-svn: 199125
2013-05-01This patch breaks up Wrap.h so that it does not have to include all of Filip Pizlo
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
2013-04-22Move C++ code out of the C headers and into either C++ headersEric Christopher
or the C++ files themselves. This enables people to use just a C compiler to interoperate with LLVM. llvm-svn: 180063
2013-01-02Move all of the header files which are involved in modelling the LLVM IRChandler Carruth
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
2012-12-03Use the new script to sort the includes of every file under lib.Chandler Carruth
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
2012-11-25Code Custodian:Joe Abbey
- 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
2010-03-02Add Module functions in place of module providers.Erick Tryzelaar
llvm-svn: 97608
2010-02-15Simplify.Daniel Dunbar
llvm-svn: 96269
2010-01-27Kill ModuleProvider and ghost linkage by inverting the relationship betweenJeffrey Yasskin
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
2010-01-09"In order to ease automatic bindings generation, it would be helpful if ↵Chris Lattner
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
2009-08-11Change llvm-c's ordering of contexts to make it consistent.Erick Tryzelaar
llvm-svn: 78656
2009-07-02Ack, missed one incompatibility.Owen Anderson
llvm-svn: 74695
2009-07-02Restore other bits of the C API that I tore up. All pre-existing APIs ↵Owen Anderson
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
2009-07-01Hold the LLVMContext by reference rather than by pointer.Owen Anderson
llvm-svn: 74640
2009-07-01Add a pointer to the owning LLVMContext to Module. This requires threading ↵Owen Anderson
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
2008-02-20Unbreak build with gcc 4.3: provide missed includes and silence most ↵Anton Korobeynikov
annoying warnings. llvm-svn: 47367
2007-12-29Remove attribution from file headers, per discussion on llvmdev.Chris Lattner
llvm-svn: 45418
2007-12-19Adding bindings for memory buffers and module providers. SwitchingGordon Henriksen
to exceptions rather than variants for error handling in Ocaml. llvm-svn: 45226
2007-12-11Adding Ocaml bindings for the bitreader as requested by SarahGordon Henriksen
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