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

[Alp Toker]

On 11/11/2013 04:51, Reid Kleckner wrote:
> I don't think NDEBUG is that easy.  We use assert liberally[1] in
> templated code in headers.  What about cast<>, which has
> assert(isa<...>...)?  On ELF, you have an ODR problem, and you'll get
> either one or the other based on the whims of the dynamic linker.

I have llvm_assert() working already. The patchset is large but split
out and reproducible.

The majority of checks change to llvm_assert(), and the ones that depend
on NDEBUG change to llvm_debug_assert(). Together they solve ODR neatly.

This also fixes the long-standing kludge of undefining/redefining NDEBUG
in the build system, lets you build genuine Release+Asserts, fixes the u
n r e a d a b l e UTF-16 MSVC assert() output and breaks the awful debug
C++ MSVCRT dependency on the on Windows. NDEBUG had a lot of baggage
that we don't really want.

Best of all, you get beta release builds with asserts enabled to provide
useful feedback during the development cycle that are still reasonably
optimised.

(I've got a feeling this could also turn out to be an easy way to
provide symbolisation based on asserts in an unevaluated context the
same way it's already done with llvm_unreachable(). The information is
lost in Release with the old setup.)

So, the patchset is a bit large for the list. Any suggestions where to
post it?

Alp.


>
> You could probably get things to the point that it sort of works, but
> I don't think we could support it without testing.  We could test
> linking Release clang to Debug LLVM (heck, that probably works, ODR
> problems aside).
>
> [1] http://llvm.org/docs/CodingStandards.html#assert-liberally
>
>
> On Sun, Nov 10, 2013 at 5:42 AM, Alp Toker <alp at nuanti.com
> <mailto:alp at nuanti.com>> wrote:
>
>     With the recent thread on using C++11 in LLVM/clang, one of the
>     recurring themes was a desire to make the internal headers more
>     consumable.
>
>     While I don't personally want any kind of stability guarantee for
>     internal headers, I do think we can do more to ensure that any
>     given snapshot of the headers is consumable from different
>     compilers and build configurations.
>
>     In practice this means removing certain preprocessor conditionals
>     under include/ and eventually introducing a config.h in order to
>     make structures stable across different configurations.
>
>     So here's a concrete proposal...
>
>     The most common violations I can see at present are in
>     llvm/Support, so if we skip over it for now (as a candidate for
>     making private), what remains is actually fairly realistic to
>     clean up...
>
>     *#ifndef NDEBUG*
>
>     This is the biggest violation. NDEBUG should only ever be used in
>     source files. That way if something is crashing we can swap in a
>     debug build without rebuilding every single dependent application.
>     Win!
>
>     *undefs*
>
>     Some examples from llvm/include and clang/include:
>
>     |#undef NetBSD||
>     ||#undef mips||
>     ||#undef sparc||
>     ||#undef INT64_MAX||
>     ||#undef alloca|
>
>     This is not OK to do globally -- even if LLVM doesn't care about
>     the definition, maybe embedding applications or OS headers do?
>
>     |$ find include -iname '*.h' | xargs grep '^#' -- | grep -vE
>     '^.*:.*(LLVM_|cplusplus|endif|else|include|define )'| grep -vw
>     Support | wc -l||
>     ||      ||*57*|
>
>     I think it's perfectly realistic to get that number down to 0.
>
>     We can start by putting a check like that in the build system,
>     first to emit a warning, and ultimately to make violations a build
>     error.
>
>     This is something we can start working towards today. Any objections?
>
>     Alp.
>
>     -- 
>     http://www.nuanti.com
>     the browser experts
>
>
>     _______________________________________________
>     cfe-dev mailing list
>     cfe-dev at cs.uiuc.edu <mailto:cfe-dev at cs.uiuc.edu>
>     http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>

-- 
http://www.nuanti.com
the browser experts