[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers
clattner at apple.com
Fri Jan 3 14:04:00 PST 2014
On Jan 3, 2014, at 1:55 PM, Chandler Carruth <chandlerc at google.com> wrote:
> > The key thing then is to make sure that it's safe to enable the
> > assertions in the headers if an application is built with !NDEBUG and
> > linked against an NDEBUG version of LLVM.
> Sounds great. I'm pretty confident that there will be no problems - in practice - from any ODR violations that might arise from "assert" differing across library boundaries. We would want some pretty strong practical justification for breaking away from standard assert.
> Sorry to dig up this thread, but when re-reading it, I was surprised that everyone seems to think this will be easily done across all of LLVM.
> How can we support AssertingVH, which behaves as a POD-like struct around a pointer in NDEBUG, and as a class with significant (important) functionality to implement asserts on dangling value handles in !NDEBUG builds?
> While having different components of LLVM and consumers of LLVM able to intermix NDEBUG and !NDEBUG built code freely without ABI issues is nice-to-have in my book, the functionality provided by AssertingVH is significantly more nice-to-have, and I don't see any easy ways to contain or limit the exposure of this facility to library-level consumers.
I hadn’t considered AssertVH, and I agree that losing it isn’t an option.
Would it be possible to redesign AssertVH to be non-ABI fragile across debug/release builds? I haven’t looked at it recently, but maybe it could be a pointer to a CallbackVH in the debug mode, or a PointerUnion<rawpointer, callbackvh> or something.
> We also have quite a few places in LLVM today that conserve memory usage in non-assert builds by removing unnecessary members of classes. We can say that this makes the ABI more fragile, but it is a valuable space optimization. Chris, are you saying to strongly believe that these should only be allowed for classes that are not visible in the C++ API? I find that surprising, as LLVM has historically prioritized efficiency and developer tools over ABI stability in our C++ APIs. Build-level instability is certainly a different beast from version stability, but I wanted to make sure the ramifications of this shift were being considered by everyone. (They hadn't by me.)
Do you have any specific examples in mind?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the llvm-dev