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

On 11/11/2013 07:37, NAKAMURA Takumi wrote:
> 2013/11/10 Alp Toker <alp at nuanti.com>:
>> #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!
> I wish;
>
>   - NDEBUG may not modify API. class structure (member offset, vtables)
>     should be stable and identical among Release builds and Debug builds.
>   - NDEBUG may keep and add facilities.
Done :-)

The patchset is 532K so I've put it online:

  http://www.nuanti.com/tmp/llvm-api-stability/

The bulk edits are split out and noted. They were refactored with an
internal tool, so it's not a big hassle to keep this up to date until
3.4 is out the door.

A handful of fixes were needed to add support for Release+Assert builds
and these are also separate commits.

TableGen and internal tools continue to use ordinary platform assert() /
NDEBUG (I think a few uses might have been incorrectly changed, will
check over), as do the C++ sources and non-public headers.

llvm_assert() is a bit more verbose but it actually fits into the coding
style well, and it's grown on me.

Extract from README.txt:

|This patchset against LLVM r194356 implements API stability.||
||
||Embedding is now fully independent of build configuration, with the
exception of C++11 feature checks in Compiler.h which still need to be
autoconf'ed.||
||
||External applications should include llvm-config.h. ||
||
||Only supported with the CMake build system, Makefile is TBD.|

Alp.

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131111/7fe81855/attachment.html>

On Nov 11, 2013, at 9:56 AM, Alp Toker <alp at nuanti.com>
wrote:
> Done :-)
> 
> The patchset is 532K so I've put it online:
> 
>   http://www.nuanti.com/tmp/llvm-api-stability/
> 
> The bulk edits are split out and noted. They were refactored with an
internal tool, so it's not a big hassle to keep this up to date until 3.4 is
out the door.
> 
> A handful of fixes were needed to add support for Release+Assert builds and
these are also separate commits.
Whoa whoa whoa.  Why are you introducing an llvm_assert() macro?  The use of
assert in header files is not a problem for "libraries", it is things
like:

#ifndef NDEBUG
  int SomeNewVariable;
#endif

in a class.

-Chris

-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20131111/43c0963c/attachment.html>

On 11/11/2013 19:08, Chris Lattner wrote:
> On Nov 11, 2013, at 9:56 AM, Alp Toker <alp at nuanti.com
> <mailto:alp at nuanti.com>> wrote:
>> Done :-)
>>
>> The patchset is 532K so I've put it online:
>>
>>   http://www.nuanti.com/tmp/llvm-api-stability/
>>
>> The bulk edits are split out and noted. They were refactored with an
>> internal tool, so it's not a big hassle to keep this up to date
until
>> 3.4 is out the door.
>>
>> A handful of fixes were needed to add support for Release+Assert
>> builds and these are also separate commits.
>
> Whoa whoa whoa.  Why are you introducing an llvm_assert() macro?  The
> use of assert in header files is not a problem for "libraries",
it is
> things like:
>
> #ifndef NDEBUG
>   int SomeNewVariable;
> #endif
They're both are a problem. assert() is defined deep down in the C
library headers and is conditional on !NDEBUG. It's not practical to
override the preprocessor define, at least with the MSVC and OS X
headers. (It _might_ be possible to hack around with glibc headers but
I'm not certain.)

That means that, as long as there are assert() uses in the headers and
you want to have a standard definition usable from a non-debug build,
you need a custom assert() macro.

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.

Alp.

>
> in a class.
>
> -Chris
>
-- 
http://www.nuanti.com
the browser experts