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

[Chandler Carruth]

On Tue, Nov 12, 2013 at 1:20 AM, Chris Lattner <clattner at apple.com> wrote:

> n Nov 11, 2013, at 12:09 PM, Alp Toker <alp at nuanti.com> wrote:
>
> >> Even when you have a !NDEBUG build, the platform assert() is pretty
> >> crummy on Windows and generates, at best a UTF-16 dump, or sometimes
> >> just pops up a dialog. WebKit and other projects take the same approach
> >> and define their own assertion macros to deal with this portably.
> >>
> >> So as far as I can tell, as long as the headers use assert(), they need
> >> to use our own version in order for the definition to match.
> >
> > Chris,
> >
> > Having said that, I agree it's worth trying without llvm_assert() to see
> > how far it gets.
> >
> > I'll pull together a rework of this patchset with just the build system
> > and structure changes alone to see how far it gets.
> >
> > 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.

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.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140103/44c41c65/attachment.html>