[LLVMdev] [cfe-dev] Goal for 3.5: Library-friendly headers

[Chris Lattner]

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?

-Chris
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140103/d061eb1c/attachment.html>