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

Alp Toker alp at nuanti.com
Tue Jan 7 20:06:47 PST 2014

On 07/01/2014 18:26, Chris Lattner wrote:
> On Jan 3, 2014, at 4:36 PM, Chandler Carruth <chandlerc at google.com 
> <mailto:chandlerc at google.com>> wrote:
>> I just don't see why this substantial complexity and lower 
>> performance of AssertingVH is worth having the ability to mix and 
>> match NDEBUG and !NDEBUG translation units both in LLVM and in 
>> consuming libraries.
>> I thought the motivation was for user code to turn assertions on and 
>> off in their code without re-building LLVM to match? That would be 
>> addressed by just making the assertions in LLVM keyed off of an 
>> LLVM-specific build time flag (like any of the other ABI impacting 
>> such flags, for example the particular subset of C++11 supported).
>> Is there some other use case?
> Chandler and I spoke about this a bit on IRC, he convinced me (not 
> that I’m the only voice here :) that there isn’t a strong motivation 
> for doing this:

Agreed. AssertingVH is not a big deal at the moment, especially once we 
get an LLVM_DEBUG macro so it doesn't get hosed due to the target NDEBUG 

If someone suggests a tidy way to factor it away though that doesn't 
affect performance or readability I'd be supportive.

In general I'm fine with the direction to keep these header conditionals 
to a minimum without cracking down on them with an iron fist. Usually 
there's a better way to do it and there's an inherent value in keeping 
the asserts build as structurally similar to the non-asserts build as 


> even today you can build llvm as release+asserts and clang 
> debug+asserts, which is the most common mixed mode.
> -Chris

the browser experts

More information about the cfe-dev mailing list