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

[Chandler Carruth]

On Fri, Jan 3, 2014 at 5:08 PM, Alp Toker <alp at nuanti.com> wrote:

>
>> 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?
>>
>
> This was in the original patch. If you have a moment I recommend that you
> take a look, particularly at the config.h change which is still the current
> 3.5 plan (the llvm_assert changes which make the bulk of the patch aren't
> in the plan for now though).
>
> To summarise, it's a matter of replacing the 5 or so structurally
> significant NDEBUG with a LLVM_DEBUG_BUILD macro definition in the
> generated llvm-config.h header.
>
>
>
>> 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.
>>
>
> As explained above, we will retain AssertingVH exactly as is, with the
> structure adapting exactly as it does now to include extra bits and asserts
> between DEBUG and NDEBUG.
>
> The only difference is that the macro definition will be in llvm-debug.h
> so it'll be stable independent of external project configurations.


If we're going to have structural differences between an asserts and a
no-asserts build, why should we stress about minimizing them? That is, why
not just s/NDEBUG/LLVM_NDEBUG/g (conceptually, not textually of course) and
provide a per-build stable idea of whether "asserts" are on or off?

That would seem way simpler, and would allow library users to define NDEBUG
which ever way they wanted without any impact on LLVM. It would also allow
us to not think about whether or not the uses of NDEBUG that are left in
the headers are "safe" ODR violations (something I'm pretty suspect about
to begin with in an LTO-enabled world).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20140103/92711de0/attachment.html>