Date: Tue, 6 Sep 2016 20:01:15 +0000 (UTC) From: Dimitry Andric <dim@FreeBSD.org> To: src-committers@freebsd.org, svn-src-projects@freebsd.org Subject: svn commit: r305496 - projects/clang390-import/contrib/libc++/include Message-ID: <201609062001.u86K1FRK001104@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
Author: dim Date: Tue Sep 6 20:01:15 2016 New Revision: 305496 URL: https://svnweb.freebsd.org/changeset/base/305496 Log: Move inclusion of <cstdio> and <cstdlib> in the -fno-exceptions case to the end of libc++'s <exception>. This is a workaround for building Firefox, which generates a rather convoluted maze of standard library wrapper headers, and this leads to an unfortunate sequence of: 1. wrapper <new> includes libc++ <new>, 2. which includes wrapper <exception>, 3. which includes libc++ <exception>, 4. which includes wrapper <cstdio> (because of -fno-exception), 5. which includes libc++ <new> again, 6. which includes mozalloc.h, 7. which tries to declare operator new with std::bad_alloc, 8. which gives an error because std::bad_alloc is not yet defined. The <new> inclusion at step 5 does nothing, because the header guard for <new> was already encountered in step 1. Then when moz_alloc.h tries to use std::bad_alloc, it is not yet defined, because we are still busy processing <exception> (where this class is defined) from step 3. Mozilla has https://bugzilla.mozilla.org/show_bug.cgi?id=1269171 for this, reported by Jan Beich (jbeich@), but when the fix for it is applied to Firefox, we get into another, similar problem situation: 1. some header includes wrapper <exception>, 2. which includes libc++ <exception>, 3. which includes wrapper <cstdio> (because of -fno-exceptions), 4. which includes mozalloc.h, 5. which includes wrapper <new>, 6. which includes libc++ <new>, 7. which gives an error defining std::bad_alloc, because std::exception is not yet defined. At step 3, we were at the top of libc++'s <exception>, and at that point std::exception is not yet defined. At step 6, <new> does include <exception> again, but similar to step 5 in the previous problem case, the header guard was already encountered, so the whole header is skipped. In upstream libc++'s later revisions r279744 and r279763, the reason for including <cstdio> and <cstdlib> was nullified again, but these commits are rather large and intrusive. Therefore, move the includes to the bottom of the file, just before where they are needed. At that point, std::exception is already fully defined. Suggested by: Jörg Sonnenberger Modified: projects/clang390-import/contrib/libc++/include/exception Modified: projects/clang390-import/contrib/libc++/include/exception ============================================================================== --- projects/clang390-import/contrib/libc++/include/exception Tue Sep 6 19:54:52 2016 (r305495) +++ projects/clang390-import/contrib/libc++/include/exception Tue Sep 6 20:01:15 2016 (r305496) @@ -80,10 +80,6 @@ template <class E> void rethrow_if_neste #include <__config> #include <cstddef> #include <type_traits> -#if defined(_LIBCPP_NO_EXCEPTIONS) -#include <cstdio> -#include <cstdlib> -#endif #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER) #pragma GCC system_header @@ -255,6 +251,11 @@ rethrow_if_nested(const _Ep&, typename e } // std +#if defined(_LIBCPP_NO_EXCEPTIONS) +#include <cstdio> +#include <cstdlib> +#endif + _LIBCPP_BEGIN_NAMESPACE_STD template <class _Exception>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201609062001.u86K1FRK001104>