[PATCH][llvm-c] Make it possible to include llvm-c without including C++ headers

[Evan Cheng]

LGTM. Committed as r178713.

Evan

On Mar 30, 2013, at 12:03 PM, Filip Pizlo <fpizlo at apple.com> wrote:

> Hi everyone!
> 
> This patch adds the ability to include llvm-c without including the C++ headers even #if defined(__cplusplus).  It allows a client of the LLVM C API to declare that they are not interested in the wrap/unwrap functions, and hence have no need for the C++ includes.  For example they do this by saying:
> 
> #define LLVM_DO_NOT_INCLUDE_CPP_HEADERS
> #include <llvm-c/Analysis.h>
> #include <llvm-c/ExecutionEngine.h>
> #include <llvm-c/Core.h>
> #include <llvm-c/Target.h>
> #include <llvm-c/Transforms/Scalar.h>
> 
> If you don't #define LLVM_DO_NOT_INCLUDE_CPP_HEADERS, you get the current behavior.  Hence this ought not require any changes for existing LLVM clients.
> 
> This is part of exploratory work for adding LLVM as a JIT backend for WebKit's JavaScript engine (see https://bugs.webkit.org/show_bug.cgi?id=112840).  We are using the C API.  This patch side-steps a number of problems we encountered on the build system front when integrating with LLVM:
> 
> - Warnings (that get treated as errors) emitted by WebKit's build system due to LLVM C++ code naming parameters even if they are unused.  WebKit and LLVM have opposite styles for parameter naming.  In WebKit an unused parameter must never be named; if it is then you get a compile error (-Werror, -Wunused-parameter).  In LLVM parameters tend to always be named.  One alternative to my small patch would be to change either WebKit's or LLVM's coding convention.  This would be hard to do.  Another alternative is to use pragmas to disable those warnings around the #include's of LLVM's headers.  Here's an example of a warning that we would get:
> 
> /Volumes/Data/pizlo/fourthTier/primary/OpenSource/WebKitBuild/Debug/usr/local/include/llvm/ADT/FoldingSet.h:355:44: error: unused parameter 'IDHash' [-Werror,-Wunused-parameter]
>                                  unsigned IDHash, FoldingSetNodeID &TempID) {
> 
> - Warnings (that get treated as errors) emitted by WebKit's build system due to LLVM C++ code not marking noreturn functions as such.  Ports of WebKit that use clang tend to compile with -Wmissing-noreturn.  Again, we could fix LLVM's C++ code, or stop compiling WebKit with -Wmissing-noreturn, or we could use pragmas.  This patch seemed like the most straight-forward solution.  Here's an example of a warning that we would get:
> 
> /Volumes/Data/pizlo/fourthTier/primary/OpenSource/WebKitBuild/Debug/usr/local/include/llvm/IR/User.h:68:41: error: function 'operator delete' could be declared with attribute 'noreturn' [-Werror,-Wmissing-noreturn]
>  void operator delete(void*, unsigned) {
> 
> - Longer-term problems with integration due to different C++ warning levels on different C++ compilers.  WebKit gets compiled by 6 different build systems (Visual Studio, Xcode, CMake, GNU Automake, QMake, and Gyp) and at least two compilers (gcc and clang, but sometimes also commercial compilers).  Although right now the LLVM backend is only on a branch and is developed on one port (the Mac port), we would expect that if it's successful then other ports will start adopting it.  It would be great to not have to think about whether LLVM's C++ headers compile with the combination of warnings and settings that each WebKit port uses. I think this patch accomplishes that.
> 
> This patch also has the nice side effect that for dependency tracking and integration we only have to worry about 200KB of LLVM headers in the C API, rather than than >8 MB of headers total.  Of course the C API doesn't include all of those headers; but it's much easier to draw the line of which headers we need if we can guarantee that the C API never includes the C++ API.
> 
> <llvm-c_do_not_include_cpp_headers.patch>_______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits