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

[Reid Kleckner]

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.

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> 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
> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20131110/39f4e65b/attachment.html>